× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



ALCOBJ will not help my situation.
The issue is that I need to end jobs if there are locks.
ALCOBJ will not solve that.

The other main factor is that these DLTLIB(S) are multiple sequences called from AJS, Advanced Job Scheduler.
Because I'm using AJS, a loop is not possible.
IBM support suggestted using the WRKWCH if a DLTLIB would fail because of a lock.

I've added the TAATOOL/RTVJOBSTS with a loop within the WRKWCH.
All is working with desired result.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John Yeung
Sent: Wednesday, May 25, 2016 11:34 AM
To: Midrange Systems Technical Discussion
Subject: 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.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.