other way I know to have both, cake and eat it too, is to use JES2 job
groups, I've played around with JES2 batch scheduling and defining job
groups, and I've had a user test this also, not so easy but an option if
you want no-delay and dependent job execution without using a scheduler
https://www.ibm.com/docs/en/zos/2.3.0?topic=statements-configuring-activating-job-groups
JES2 needs to be active in Z22 MODE
Carmen
On 3/4/2022 8:29 AM, Joel C. Ewing wrote:
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 <[email protected]> On
Behalf Of Paul Gilmartin
Sent: Thursday, March 3, 2022 4:51 PM
To: [email protected]
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
--
/I am not bound to win, but I am bound to be true. I am not bound to
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
