Sorry, I can't buy that. Use a job scheduler for this type of thing... Or use a "single threaded" job class (with only one initiator).
Other than the example I gave originally my other issue with this is in development. In my opinion (yes, going against the grain again) you should not have to submit jobs with your initials as the first part of the name. If that's the case then anyone can name their job anything. Well if two people happen to name their job the same thing (say, PRNTVSAM, which is pretty common here) then job 1 can hold up job 2. What's the good of that? The whole thing with putting your initials as part of the job name annoys me as well. I don't do it. When I use SDSF and I want to see my jobs only then I just do "OWNER FJS" (having already done "PRE *"). No fuss, no muss. This allows programmers in the DEV/TEST LPAR to use the production job names. And all is good. I'm sure others will disagree... I notice that NODELAY is actually the default if the DUPL_JOB parm is omitted altogether. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 10/2/2009 at 1:34 PM, in message <[email protected]>, Dave Salt <[email protected]> wrote: > Hi Frank, > > > > I used to work at a place that HEAVILY relied on the fact that jobs with the > same name would only run one at a time. For example, job one might stop the > areas of hundreds of IMS data bases, job 2 might delete and define all the > areas, and job 3 might start all the areas. Obviously these jobs have to run > in the right sequence, so the ability to set them all as the same job name is > extremely convenient. And we couldn't put all the steps in a single job, as > it would exceed the number of steps allowed (256 if memory serves?). > > > > As others have pointed out, there's no guarantee that creating jobs with the > same name means they'll all run in the same order that they're submitted. But > in practice they did, especially as there was usually a gap of several > seconds between each job being submitted. > > > > In my opinion, the fact that jobs with the same name only run one at a time > is a very good thing. And if you want jobs to run in parallel, it's not that > difficult to change the jobcard from //myjobA to //myjobB before submitting. > > > Dave Salt > > SimpList(tm) - try it; you'll get it! > http://www.mackinney.com/products/SIM/simplist.htm > > > >> Date: Fri, 2 Oct 2009 12:43:38 -0600 >> From: [email protected] >> Subject: multiple jobs / same name >> To: [email protected] >> >> I have a complaint (shocking, I know). What is the reasoning behind MVS not > allowing more than one job with the same name to run at the same time? For > instance just now I wanted to do an IDCAMS PRINT on two files. I do this > often on VSE with a job I have set up that has this: >> PRINT INFILE(FILE1) - >> DUMP >> >> I simply change FILE1 to whatever the name is and submit it. Then if I have > another one I change it again to the second file and submit it. These are > large files so it makes sense to have them both run at the same time, rather > than one after the other. But unless I change the job name on the JOB card on > z/OS the second one won't run until the first is done. Annoying! Why on earth > is this restriction present? Does it actually *help* some situations, or is > it simply one of those annoying things that has existed forever and will > probably never be changed? >> >> Thanks (really!), >> Frank >> > > _________________________________________________________________ > Internet explorer 8 lets you browse the web faster. > http://go.microsoft.com/?linkid=9655582 > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html >>> The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
