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 <jcew...@acm.org> >To: IBM-MAIN@LISTSERV.UA.EDU >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:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of John McKown >> Sent: Wednesday, May 01, 2013 10:05 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> 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 jcew...@acm.org > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
