One concern I might have is the fact some processes were set up with the following philosophy
Submit all jobs at once, and the enqueue will keep them from running concurrently. One at a time will run. So, if you change even one job to be able to run concurrently instead of serially, it might create for some interesting events. This might make some companies rethink their job control processes. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Steve Thompson > Sent: Monday, January 06, 2014 6:33 AM > To: [email protected] > Subject: DSENQSHR -- Caveats? > > In reading the doc on DSENQSHR (in JCL, JES, GRS, etc.), I am wondering what > the down side might be. > > If one is using a Production Control system of some kind, what pitfalls do you > envision by allowing an ENQ to be demoted to non-exclusive (SHR)? > > I can see problems for restart if a file gets mangled during reorg, or > delete/define/load that is detected by the next step which uses DISP=SHR as an > example. Granted, that JOB should RUN with DSENQSHR=DISALLOW. > > > Regards, > Steve Thompson > Humana, Inc. > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
