cancel
Showing results for 
Search instead for 
Did you mean: 

KERNEL - NW 7.0 UNICODE - PL 159 - VR54 O/S - ALL IMPORTS FAIL

Former Member
0 Kudos

Is anyone sucessfully running .....

KERNEL NW 7.0 Unicode - patch level 159 on VR54?

Due to a kernel issue we hit (OSS 1157026) at kernel patch level 151, we needed to move to a minimum level PL of 156.

Available on SAP marketplace at the time was 159

So we took almost ALL .sar files which had been updated since our previous patch in March (level 151)

Once we patched to 159, the ability to import failed. Observations, the import begins and ends up just hanging. Opened a CSS message and left the kernel in place, but the message volleyed around without progressing.

Our ECC 5.0 to ECC 6.0 upgrade and Unicode conversion GO-LIVE is June 16th --- so the ability to transport to our QA environment is extremely critical at this point. We had to put the kernel back.

Now, we are hitting critical GW hang issues which needs the new kernel to resolve.

So we sit with 2 GO-LIVE showstoppers

1 - patch the kernel and loose ability to import but GW is good

2 - Don't patch the kernel so that imports work BUT GW hangs

Is anyone running this combination with success?

Any creative ideas?

btw - for those not familiar - we've been sucessfully running R/3 on AS/400 / i5 for 10 years; so hope we've debugged the obvious here.

The biggest disappointment here is that the rest of our NW 7.0 environments BI / PI / EP are all sucessfully running KERNEL 159. They are all Wintel w/ MS SQL SERVER 2005 DB.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Doreen,

As you know we have been working on these tp issues in house as well, based on another customer message where the issue was reproducible. By Friday we had also managed to isolate the coding in DBSL which is apparently causing the issue but we haven't yet managed to find the error, though the problem is being addressed with high priority here. My recommendation would be to implement the latest DBSL patch level which does not contain the suspect code and this is 153. It should not cause any problems if this is implemented with the latest DW-patch.

Regarding the STOPSAP issue. You will eventually need to make sure that all the patches listed in note1154138 are on at least the level mentioned there. Unfortunately, there has been a problem with the delivery of the KILL and SAPROUTER patches, so we don't have the complete set out on SMP yet. The SAPROUTER patch is not relevant for the starting and stopping of the SAP system but the KILL patch is, unfortuantely. I will get back to you as soon as it is available.

Regards,

Sally Power

Dev. Support for SAP on IBM i

Former Member
0 Kudos

Hi Doreen,

all of this makes really a lot of sense and is really good news to me )))

The LIB_DBSL is not needed. So, we can choose between 159 or 161 whatever you prefer.

The STOPSAP either gets fixed with the KILL or is no issue at all => The kernel hopefully works fine and we can move forward

(and walldorf is working on the LIB_DBSL issue, that is not really relevant for us)

Regards

Volker Gueldenpfennig, consolut international ag

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

Former Member
0 Kudos

Want to quickly get back to you that we do not have LIB_DBSL 153

The last version we were running was PL 151 on SAP marketplace but when

viewing it in SAP we saw 147.

This is what caused us to create CSS 223818

We want to respond to all of this new information quickly and

effectively, so want to confirm LIB_DBSL 153 the level we need to

obtain and it is clean even though we've never run that before?

Please confirm this and also the location where we will be able to

obtain it from.

Regards

Doreen & Diane

Former Member
0 Kudos

Hi Doreen,

I already answered this question in your message. The 157 pach has been withdrawn, since it's causing problems and the 153 patch has been reinstated on the SAP Service Marketplace. You can retrieve it from there.

All the best,

Sally Power

For Dev. Support on IBM i

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Doreen,

I didn't dig into that issue by now on your site.

But, do you know, what in detail is the issue with the TP stuff ?

I would suggest the following:

Create a "slim159 kernel" with just DW & LIB_DBSL - this is in normal case consistent and most likely doesn't crashes transports ))

You can give me a call on my cell when we should chat on that.

Regards

Volker Gueldenpfennig, consolut international ag

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

Former Member
0 Kudos

Hi Volker -

We did build a "slim" kernel BUT maybe not quite "slim" enough because we also took ENSERVER.

We are in a very bad situation here with our iSeries ECC which will NOT go live (June 16th) until we resolve this.

To get imports working again, we backed down to level 151 which now has GW failures and have a CSS message open on that.

The lastest from SAP support is to back the kernel to level 133 but that is NOT acceptable (see OSS NOTE 1132350)

_SUMMARY for our ECC on iSeries environment_

KERNEL 133 is not acceptable (see OSS NOTE 1132350)

KERNEL 151 is having GW failures (see CSS 397794)

KERNEL 159 doesn't allow for imports

To add to the frustration is that ALL of our brand new SAP on Intel w/ MS SQL SERVER 2005 DB (EP / PI / BI) installs are running beautifully on KERNEL 159. They can GO-LIVE on June 16th but it won't matter without ECC.

Regards

Doreen

Former Member
0 Kudos

Hi Doreen,

as mentioned already:

I would suggest to build a kernel JUST based on DW and try this - this seems to be an easy stuff, as you should have "some systems" around, where you can put this kernel to and try to import then ...

I fully understand, that this would be a showstoppen for you ....

Regards

Volker Gueldenpfennig, consolut international ag

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

Former Member
0 Kudos

Hi Doreen,

as I had it in mind:

In the menatime, there is 161 out ... should I patch that one for you and apply it somewhere in your Q-systems ?

Regards

Volker Gueldenpfennig, consolut international ag

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

Former Member
0 Kudos

Just built a skinnier KERNEL 159 patching only DW & LIB_DBSL; applied to sandboxECC; imports still fail.

Next will be to try a very skinny KERNEL 161 patching ONLY DW

Regards

Doreen

Former Member
0 Kudos

BUILT A NEW KERNEL WITH ONLY disp+work 161 and the imports are successful.

Will next build a 159 kernel with only disp+work and test.

Sounds like we are narrowing in on LIB_DBSL to be the root cause of the issue.

Former Member
0 Kudos

Hi Doreen,

that is at least good "in between news" )))

... have to go to bed now ....

Regards

Volker Gueldenpfennig, consolut international ag

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

Former Member
0 Kudos

BUILT A NEW KERNEL WITH ONLY disp+work 159 and the imports are successful.

With both dispwork 159 & dispwork 161 SAP doesn't come down all the way (this was observed with/without LIB_DBSL and with/without ENSERVER)

Not sure what the lesser of evils are here -


we can now import but can not STOPSAP all the way.

The following jobs are left running after issuing STOPSAP......

They never come down

MSGSERVER

RSLGCOLL

RSLGSEND

We've now proven that the current LIB_DBSL on SAP Marketplace (posted May 16, 2008) PL157 is the root cause of the issue.

We will update our CSS message and see how things proceed - we are very interested in determing if 159/161 fixes all of our RFC / GW issues --- but without the ability to STOP SAP, don't like this behavior and/or trust whether it would be safe to run either of these.

Regards

Doreen