I stress again, I am not trying to find an alternative to using delay in this
manner. I am trying to determine what job are USING delay in this manner.
________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of
Joel C. Ewing <[email protected]>
Sent: Friday, March 4, 2022 7:29 AM
To: [email protected] <[email protected]>
Subject: Re: JES2 DUPL_JOB parameter
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
>
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
