Prestart job locking old World library

tcsbiz

Member
Hello everyone. I'm working for an organization that has JD Edwards World and One World on a system i at V5R3. The current JDE version is XE version B7333 SP 23 Update 6.

A couple of weeks ago, on a Sunday night, the sys admin, with instructions from a JDE consultant copied all of their data from the World system to the One World on the i. The original data library was FSVPRDTTA and the new data library is PRODDTA. All JDE data resides on the i.

I heard about the move on Tuesday when users using systems that interface to JDE were not seeing the proper data from the address book. And, users who send data into JDE had the data going to the FSVPRDDTA instead of PRODDTA.

Since then, I've made changes to job descriptions, initial programs, interface programs, and logical files. All of the interfacing users are sending their data to the right place and everyone seems to be working fine accessing the proper libraries.

So, you might ask "what's you're problem"? The problem is that there was a lock on FSVPRDDTA when the sys admin attempted to remove it. The lock is from a prestart job in QUSRWRK called QZDASOINIT. The user on the job is QUSER but it is running with user JDE. The user portion of the job's library list has FSVPRDDTA. The user JDE has an initial program defined called J98INIT.

My question is: where is FSVPRDDTA being added to the library list? I suspect that J98INIT is doing this. J98INIT is a CL program. I don't have the source and am prevented from doing RTVCLSRC on it.

I'm knowledgeable about JDE on the interface end of things. I know the files and how to work with them. I've never administered JDE before and know nothing about the JDE PC client. The primary JDE users in the Finance dept. access the data residing on the i using the PC client software.

We need to prevent the use of FSVPRDDTA. How do we do that?

I checked the internet for J98INIT and found a PDF document from 1998 titled World Software Guide. It explains how J98IN IT and J98INITA work. Is there a different version of J98INIT I need to use that will use PRODDTA?

I really appreciate any help. Thank you very much.

Tom.

XE version B7333 SP 23 Update 6
AS400/iSeries/i5/i (take your pick) at V5R3.
 
Does the QZDASOINIT JOBLOG show a date/time when the JDE user connected to the server? If it is old, you should be able to kill the QZDASOINIT without any issue. Finding exactly why the active connection could be tricky unless you can account for where the JDE user profile would be making an SQL connection from, using the old library.
 
DRezanka,

The QZDASOINIT JOBLOGs do show the date/time created. The JOBLOG also shows the IP address of a connected machine. We killed the jobs without IP addresses but they respawned when a PC connected. Today, we will identify the users by IP address and try to identify commonalities among them.

Thank you for your help.

Tom.
 
1) if all QZDASOINIT jobs have this library, then you might check your system values, QUSRLIBL, QSYSLIBL
2) the QZDASOINIT job has a prestart entry definition in the subsystem that will tell you the jobd of QZDASOINIT jobs.
3) If it is just one job, then it could be that an OCM is still active in OneWorld pointing to this library. All environments/OCM's that point to this library should be disabled.
4) Could be a whole different 3rd party application that uses that library and QZDASOINIT.

you're on the right track, tracking down the client.
 
Per Elvis: Kill the QZDASOINIT job(s) that hold the lock and delete the library.
 
Thanks to everyone who helped.

This is what we came up with as the problem. It turns out that the JDE client uses the Client Access ODBC to connect to the database. The ODBC driver used by the clients have the old library in the library list.

This is being changed and then we'll see if there are locks.

Tom.
 
Another update. The ODBCs were changed and an attempt to delete the libraries was made. There were no locks this time, so, the prestart jobs were not the problem. There were logical files created against the address book in FSVPRDDTA. Those will be changed and the delete tried again.

Tom
 
This has been resolved, finally. All of the ODBC drivers have been identified and updated. The old libraries have been completely removed.

Thank you to everyone who helped.javascript:void(0)
cool.gif
 
Back
Top