Confused....

Hello all.

Here's my problem:
Oneworld xe update 6 SP20_R1 running on OS400 V5R1 working fine.
Upgrade OS400 to V5R2. Everything is fine for a week, then bang! Data goes missing, programs crash, horrible mess.
Contact Peoplesoft. They suggest upgrading SP on as400 to a 'supported' level.
I chose SP22. (Don't ask why)
Apply it. Build client update package. Deploy to a client.
Test.
Bang.
Still the same.
End user desperate because the first 'bang' happened on Monday, and here we are Thursday afternoon and the system is still unavailable...
For the reccord: CUM level TC03252, DB2 PTF level SF99502 level 9, SF99519
The biggest show-stopper observed is no sales orders! Look them up and there aren't any there! Use UTB and, yes, of course, the data is there...

I've tried all sorts of things (too numerous to mention here) all to no avail.

Any help that is quicker than the Peoplesoft response line would be gratefully appreciated.

Any info from the jdedebug.log on the client? Client access giving out in
the logs?
Regards,
Kieran Fitzgerald

Hi Mark

CUM level should be TC4077 ( This is the latest CUM Level )
Just reorder CUM pack to get latest DB/hyper ptf's

Take services down, delete are your SQLPKGs except for
the ones that start with Q and bring services back up.

--- jonesm2000 <[email protected]> wrote:
http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=OW&Number=74436




__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

We have the same expereince with Xe and SP 20. The problem was related to the Update in AS/400. The system startup well, but in 4 hours has problems with speed and all application hangs.
The problem was in the client access that was not updated. the desition was to remove all AS/400 updates, we did this and work fine.

I had already updated the client access express version on the clients, plus installed the latest service pack (SI10914) - all to no avail...

Is there anyway you can roll back the OS Update?

For gosh sakes man, get your users back up and then try to figure out what the heck happened. Go backwards to your last known good configuration.

One problem you specifically report is no sales orders returned from UTB.
Can you see the F4201 records using STRSQL? What about with the Ops Nav SQL Client? Any messages in the jde.log when you do a find on P4210? Have you deleted the JDE-related SQLPKGs?

I really feel for you. Here is what we had to do just this week in order to recover from a disaster during the weekend:

1. Delete all of the *SQLPKG files in all JDE libraries. Some of the *SQLPKG objects in the JDE libraries will be locked and won't be able to be deleted unless the JDENET is brought down.

2. Bring the system down to restricted mode, then run RCLSTG SELECT(*DBXREF) in order to build just the IBM AS/400 cross reference files. You DON'T want to run *ALL reclaim objects because it'll take too long.

3. Back up the QGPL/QZDAPKG object (another *SQLPKG object), then delete it. This is an IBM object that normally is not touched. However, when it is deleted, it will rebuild itself.

These 3 things seemed to straighten everything out for us. They may or may not work for you, but it definitely wouldn't hurt to try. I must mention that these 3 things all relate to how the system is able to find files on the AS/400. So, if you can run UTB and see the selection list of files and datasources to chose from, yet can't open the file to view the data, then this is a good indicate that the above 3 steps will fix your problem. Good luck!

he said: << ... Use UTB and, yes, of course, the data is there... >>

Hi

I've heard the SQLPKG advice from Peoplesoft too. Mainly because the jde.log has the following entry in it...

696/2912 Thu Jun 24 15:15:10 2004 JDBODBC.C5459
[IBM][iSeries Access ODBC Driver]Error in host server data stream. - SQLSTATE: S1000

However, I've taken down the OW services, even taken down host services and Qserver and deleted as many of the sqlpkgs I can find, but not all of them will delete (an example of this is ACTIVCONJA in library COPD7333). Anyway, after all that the problem still hasn't gone away.

Thanks

Mark

Look for PTF SI13910, make sure it is there. I had issues with data go missing that is there. If you can't get the PTF on, disable extended dynamic support from the ODBC settings for your fat clients. This gave us some time to get the PTF on. Also DB level is 12 now not 9.
Hope this helps some.

You need to delete all of them even if you have to do
a wrkobjlck and clear the locks that are on them, but
delete them all, except for the ones starting with Q.


--- jonesm2000 <[email protected]> wrote:
http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=OW&Number=74465




__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

Use WRKACTJOB and END all the QZDASOINIT jobs with a status TIMW. This will release the record locks on the remaining SQLPKGS you can't delete. Go back and delete them, and I bet you'll be able to get JDE back up.

I have a similar problem that has been popping up since we upgraded to V5R2 - a user will go into an application, click find, and no data will be returned. (there's no consistancy in what application it is). The solution is to take everything down and delete all the SQL packages - something I'm getting better and better at.

We're working with IBM on it.

Good advice from the folks below. Use the WRKOBJLCK command to identify and end the locking jobs. Don't forget that even though you may end the JDE subsystems, there may be other jobs running such as interoperability jobs as a process (known as a JDE subsystem job) that don't necessarily terminate just because you're ending the JDE subsystem. These types of jobs may also be locking the *SQLPKG objects.

Have you found a solution to your issue? We are having the same issues here and not getting any help from PeopleSoft yet. Any information would be appreciated.

Thank you.

We had an issue with SQL packages after upgrading to V5R2. IBM is aware of the issue. In the mean time, for a work around, we have turned SQLPKGs off.