Dave (and Frank, et al), A shop I worked for many years ago, before we installed a job scheduling system, had a "poor man's job scheduling" method: A program called "FREEJOB". This program took a list of 1 or more jobnames passed in PARM='...,...,...' and issued $A'jobname' commands. (This program or something equivalent should be available on the CBT tape) Basically, all the overnight batch jobs were submitted at one point in time in one bunch. They all had TYPRUN=HOLD in the JCL and they all had unique jobnames. (And, to make this work and avoid "duplicate jobname"-errors when executing the $A'jobname' command, all output from previous runs was archived, printed or purged prior to starting tonight's batch cycle.) Each of these jobs (except for the last job in a sequence, of course) had a last step //LAST EXEC PGM=FREEJOB,PARM='...',COND=...
So, if you had three jobs in a chain, to run one after the other, your JCL looked something like this: //JOB1 JOB ... //STEP1 EXEC ... production steps go here //LAST EXEC PGM=FREEJOB,PARM='JOB2' //* //JOB2 JOB ...,TYPRUN=HOLD //STEP1 EXEC ... production steps go here //LAST EXEC PGM=FREEJOB,PARM='JOB3' //* //JOB3 JOB ...,TYPRUN=HOLD //STEP1 EXEC ... production steps go here Condition code checking in each job must ensure that FREEJOB only executes if the running job was successful and it is OK to release the successor job(s). As I said, a poor man's method. But it worked well for us for years. It might give you an idea on how to solve your job chaining needs without the need for system changes to enforce single-threading of jobs. Of course, as someone also mentioned, instead of my FREEJOB method you could use a SUBMIT - step and submit the next job(s) in chain. Try and see what works best for you ... Regards, Ulrich Krueger -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Dave Salt Sent: Friday, October 02, 2009 12:34 To: [email protected] Subject: Re: multiple jobs / same name 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 ---------------------------------------------------------------------- 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
