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

On 24-May-2016 13:59 -0500, Steinmetz, Paul wrote:

I have a utility that finds locks and then ends those jobs. 99% of
the jobs end LT 5 seconds.
If the job is a JVM job, I've seen it take 2 to 3 minutes to end.

Be thankful not to have hit a job, yet, that is running commitment control with sufficient pending resources\work such that the wait could being perhaps some hours.

Note: only by rare exception should a job be ended *IMMED, and instead, should be ended first with *CTRLD even with a somewhat short wait. A snippet of the help text for the How To End (OPTION) parameter of the End Job (ENDJOB) command: "Note: The *IMMED value might cause undesirable results if data has been partially updated. This value should be used only after a controlled end has been attempted unsuccessfully."

Note: If the jobs that hold the locks are running a specific application, then the application might best enable an End Application Jobs (ENDAPPJOBS) feature that can be invoked, instead of the more indiscriminate ending of jobs; by a design, that can ensure proper cleanup and even allow for special-case\exception scenarios.

Is there a way to tell if the job requested to end immed has ended?

The Retrieve Job Information (QUSRJOBI) or a similar Work Management API [http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/qusrjobi.htm]. Less desirable might be a review of the history log; await the /job ended/ completion.

I'd like to add loop to this process and DLYJOB until the jobs have
ended.

Why not just loop instead, on a request allocate exclusively the same object used to decide which jobs to end? There is a Wait Time (WAIT) parameter on the Allocate Object (ALCOBJ) command to effect a timeout and continue. The use of a simple delay with Delay Job (DLYJOB) allows other jobs to obtain a new lock while sleeping, thus more jobs to end [or the code does not account for that effect, and the next step fails because there are once again conflicting jobs]; the DLYJOB with a constant Job Delay Time (DLY) also may allow useless waiting, whereby waiting continues despite all jobs\locks are gone, meaning the job in-wait could have moved on to doing something useful.