To understand the controversy over duplicate jobnames, one needs to know the history of HASP. Long decades ago HASP did not allow duplicate jobnames to run simultaneously. IBM asked the HASP community if they needed that feature and they said YES we have many users that use this "feature" to force their jobs to run one at a time (but not necessarily sequentially). That is why the feature is in JES2 and not in JES3, which has dependent job control to provide the same function.
Bill Fairchild Franklin, TN ----- Original Message ----- From: "Ted MacNEIL" <[email protected]> To: [email protected] Sent: Wednesday, May 1, 2013 2:27:22 PM 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
