Re: iSeries Service jobs creating locks, (QZDASSINIT, QZRCSRVS, etc)

On 10/25/13 9:05 AM, Steinmetz, Paul wrote:

Now that I've identified the source of the QZRCSRVS job, is there a
way to have the QZRCSRVS job end. The program that ran in this job
ended weeks ago, no open files, however, the QZRCSRVS job still has a
lock on all the libraries in the lib list. I really don't want to
ENDHOSTSVR simply get rid of the lib list locks for an environment
refresh. This is on an R&D LPAR.

FWiW the End Host Server request can be more granular than the default of ending all host servers. And specifically for the "Remote command and program call" server daemon job QZRCSRVSD plus associated server jobs named QZRCSRVS, that is effected by ENDHOSTSVR SERVER(*RMTCMD).

As a Prestart Job, the QZRCSRVS jobs can be ended separately with an ENDJOB, because another will take its place as needed, according to the ADDPJE specifications. AFaIK each server ended with ENDHOSTSVR effects ending both the daemon job and the prestart server jobs. The ENDPJ could be more specific, but I am not sure what is gained or could be problematic, by leaving the QZRCSRVSD active; similarly I am not sure of the effects ending the daemon job without ending the prestart jobs. But obviously, not ending those prestart jobs that hold conflicting locks, does not help.

If the libraries are indeed locked due to the library list, then there is the capability to have jobs not lock the libraries they place in their LIBL; i.e. via the system value QLIBLCKLVL "Library locking level". In some cases I suppose the application could be designed to /undo/ the library list setup when done; i.e. if upon starting, the libraries were added, then when ended they could be removed.? However if the libraries are there as a side effect of the connection having established the list of libraries assigned from the Job Description (*JOBD) of the user profile that connects, then the /undo/ I somewhat would expect to have been a side effect of the end of the connection; i.e. the effective job termination effected to allow job reuse of that specific prestart job, should probably have reset the library list to the user associated with the PJE [which is typically QUSER].? While the "print device and output queue are swapped from the requesting user's job description", I do not recall but I do suspect, the Initial Library List (INLLIBL) of the job description of the connecting user does as well... but I am unsure if leaving the connecting user's library list in effect after its work completes is proper\by-design or a defect.

If the issue for the locks is merely preventing DLTLIB as part of the /environment refresh/ activity, then perhaps the work being done in that refresh process can eliminate the request to Delete Library, by using the Clear Library (CLRLIB) instead? Of course irrespective of DLTLIB vs CLRLIB, other than pseudo-closed cursors, conflicting locks held by the applications would remain a problem if their work is really not ended... and also important to effect is the prevention of new connections and\or new locks held by the application for those new connections.