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.
midrange.com
