Note also that it has been mentioned before in this forum in other
contexts: submitting two jobs with the same job name in sequence and
expecting "DELAY" to force them to run in the sequence submitted is only
valid if you have a single JES2 Converter//I/nterpreter running, which I
suspect is no longer true at most installations.
If you need a specific execution order, order of job submission is not a
reliable way to achieve it, unless you delay submitting a followup job
until the first job is actually running in an initiator. With multiple
C/I's running, submitted Jobs can complete C/I processing in an
unpredictable order and reach an initiator processing queue first, even
if not submitted first.
Reliable non-manual ways of guaranteeing correct JES2 job execution
sequence either involve job1 submitting job2; or some kind of system
automation, like a job scheduler, which only submits job2 after job1
successfully completes.
Joel C Ewing
On 3/4/22 06:48, Allan Staller wrote:
Classification: Confidential
I know for a fact that we have some jobs that depend on DELAY, because I turned on
NODELAY and it caused an issue. Two jobs with the same name are submitted at the same
time (or one after the other), where job 1 copies a file to a second file, and job 2
copies the second file to a third file. With NODELAY they ran "at the same
time" so the copy from file 2 to file 3 failed because the copy from 1 to 2 was
still running.
The simple solution to this is to not only have job 1 copy the file for job2,
but also submit job2. Thus only only one job will be in the system an NODELAY
will not be needed.
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Paul Gilmartin
Sent: Thursday, March 3, 2022 4:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 DUPL_JOB parameter
[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]
On Thu, 3 Mar 2022 22:20:15 +0000, Frank Swarbrick wrote:
I know for a fact that we have some jobs that depend on DELAY, because I turned on
NODELAY and it caused an issue. Two jobs with the same name are submitted at the same
time (or one after the other), where job 1 copies a file to a second file, and job 2
copies the second file to a third file. With NODELAY they ran "at the same
time" so the copy from file 2 to file 3 failed because the copy from 1 to 2 was
still running.
Shouldn't SYSDSN ENQ resolve this?
Or did job 1 carelessly write with DISP=SHR?
(Were these Classic data sets or UNIX files?)
Would DSENQSHR alleviate or aggravate the misbehavior?
That's why I want to be able detect this and make changes before going back to
NODELAY.
And you might need to deal with ambiguity in operator commands.
And there's no guarantee that jobs will run in the order submitted.
--
gil
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
