Exactly, Ted. I have NEVER been at a shop where an operator has noticed jobs sitting in the input queue and decided to "help" by unilaterally opening another initiator to service jobs of the affected class... Notice the huge pile of sarcasm!!! :-)
Rex -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Ted MacNEIL Sent: Wednesday, May 01, 2013 2:27 PM To: [email protected] Subject: Re: Check whether job still running But, depending on that can be risky: Not all jobs are interpreted as quickly nor is order guaranteed (same as with duplicate jobnames) What happens if another initiator is opened with the same clads$l? - Ted MacNEIL [email protected] Twitter: @TedMacNEIL -----Original Message----- From: Frank Swarbrick <[email protected]> Sender: IBM Mainframe Discussion List <[email protected]> Date: Wed, 1 May 2013 10:45:00 To: <[email protected]> Reply-To: IBM Mainframe Discussion List <[email protected]> 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 The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
