Or ue the JES facilities. JES3 has been able to handle that since it was ASP, and JES2 has had it for a while now. Are there many JES2 installations so backlevel that they don't have SCHEDULE?
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Joel C. Ewing [[email protected]] Sent: Friday, March 4, 2022 9:29 AM To: [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
