Alternatively, it looks like one could do something like this: JOBDEF DUPL_JOB=NODELAY
JOBCLASS(D) DUPL_JOB=DELAY or, conversely, set only specific classes with the NODELAY option: JOBDEF DUPL_JOB=DELAY JOBCLASS(A) DUPL_JOB=NODELAY I'd be happy with either one! >________________________________ > From: Frank Swarbrick <[email protected]> >To: [email protected] >Sent: Wednesday, May 1, 2013 11:45 AM >Subject: Re: Check whether job still running > > >If one explicitly wants to force a set of jobs to run sequentially can't they >just be submitted to a class that has only a single initiator? That seems to >me to be a much better solution than depending on job names. > > > > >>________________________________ >> From: Joel C. Ewing <[email protected]> >>To: [email protected] >>Sent: Wednesday, May 1, 2013 10:07 AM >>Subject: Re: Check whether job still running >> >> >>Granted, production job schedulers are not a good fit if this is a one >>time job sequence from an application programmer or from some other user >>who would rightly lack update access to or full understanding of >>production control. If it is a frequently used job sequence and the >>user only needs to control when it is initiated and perhaps supply data >>to the jobs, then there are reasonable ways to put the jobs under a job >>scheduler and production control and give the application person a way >>to supply data and initiate the job sequence. >> >>If this level of job control is a persistent need by application >>programmers or other users for one-time job sequences, I would create >>canned JCL examples and/or PROCs and documentation showing how to >>submit "next job" JCL from a user-supplied data set or PDS member from >>within another job, with examples of how to use IF-THEN-ELSE JCL to >>conditionally fire the next job and send a message to the user if that >>were skipped. As long as you steer clear from trying to use in-stream >>JCL data to supply the next job JCL (which quickly becomes confusing as >>to which JCL goes with which job) and instead get the JCL from a data >>set, this is not a complicated process to document, and would seem to be >>a far simpler, more efficient, and safer solution than relying on data >>set enqueues or tying to ascertain the status of one job from another. >>This potentially means that a follow-up job may end up further down in >>the input queue than if submitted at the same time as the first job, but >>I suspect other users of the system would consider that "more fair" if >>they were competing for the same initiators. >> JC Ewing >> >>On 05/01/2013 09:43 AM, Farley, Peter x23353 wrote: >>> Not just your shop, John. Access to actually create or modify a job >>> schedule here is restricted to operations personnel. IMHO, a real >>> production scheduler is usually way overkill for a programmer wanting to >>> set up a few ad-hoc job sequences, not to mention that (in my experience) >>> companies don't usually bother to teach programmers how to use production >>> schedulers anyway. >>> >>> The comment earlier in this discussion (or the other similar thread) about >>> changing the DUPEJOB setting for JES2 to allow duplicate-named jobs to >>> execute simultaneously would be entirely counter-productive here, since >>> submitting your series of 10 compile and link jobs (all with the same job >>> name) would entirely flood the few initiators permitted for this purpose, >>> locking out all the other hundreds of programmers from that scarce >>> resource. One duplicate at a time measures out a very scarce resource in >>> the fairest manner, or at least in *a* fair manner. >>> >>> Still, it would be nice to have the JES3 job networking capability. Not >>> likely to go JES3 here though. >>> >>> Peter >>> >>> -----Original Message----- >>> From: IBM Mainframe Discussion List [mailto:[email protected]] On >>> Behalf Of John McKown >>> Sent: Wednesday, May 01, 2013 10:05 AM >>> To: [email protected] >>> Subject: Re: Check whether job still running >>> >>> I don't know if it is a general "problem" or only one around here (due >>> perhaps to ignorance), but in most cases, a programmer cannot _easily_ add >>> an "ad hoc" series of jobs to our CA7 system and schedule them. Not to >>> mention that the programmers don't generally have that level of knowledge >>> any way. I am not very JES3 literate, but I've heard that it solves this >>> problem with DJC (Dependent Job Control). And, of course, not letting a job >>> into an initiator when it would cause a "JOB WAITING FOR DATA SETS" message. >>> >>> ... >> >> >>-- >>Joel C. Ewing, Bentonville, AR [email protected] >> >>---------------------------------------------------------------------- >>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 > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
