Re: ENDJOB JOB(&OLJNBR/&OLUSER/&OLJNAM) OPTION(*IMMED) taking excessively long for JVM jobs.

On Tue, May 24, 2016 at 4:28 PM, Steinmetz, Paul <PSteinmetz@xxxxxxxxxx> wrote:

Chuck,

This is for the utility that runs with AJS on our R&D LPAR when we wish to DLTLIB of all the libraries for an application.
If someone forgets to signoff if some other job is running, the DLTLIB fails.
I've created a WRKWCH against DLTLIB for CPF2113 and CPF3202.
Has been working fine except for the JVM jobs that take long to end.
Between lines 143 and 154 I'm going to add a loop with TAATOOLS/RTVJOBSTS, checking the status of the job that I just ended.

Paul,

I'm quite confident Chuck fully grasps your situation. He is
suggesting that ALCOBJ is a simpler and more effective way to
accomplish what you are trying to do. ALCOBJ encompasses the work done
by (and thus can replace) both checking job status and DLYJOB. Not
only that, ALCOBJ is closer to what you REALLY want:

(1) It's not so much that you need some other job to end in order to
continue; it's that you need that other job to release its lock(s) on
something you are trying to delete. So it's more precise to check the
lock(s) (by trying to allocate what you're trying to delete) than to
check the job status.

(2) It's not so much that you want to wait some fixed number of
seconds; what you really want is to wait just long enough for the
lock(s) to go away, and not longer. Again, ALCOBJ lets you achieve
that more precise goal.

John Y.