We almost exclusively use DISP=SHR, for better or worse... Our JES2 instances are not shared. We have a Sysplex with only three LPARs, one for prod, one for dev/test and one sandbox. So I don't think we can have the issue you described.
Honestly, I don't understand why people seem to be wanting me to justify the current behavior. I am not at all wanting to justify it. I am wanting to change it. I just need to find out what jobs are depending on it. Hopefully not many! ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Paul Gilmartin <[email protected]> Sent: Thursday, March 3, 2022 3:51 PM To: [email protected] <[email protected]> Subject: Re: JES2 DUPL_JOB parameter 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 ---------------------------------------------------------------------- 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
