On Tue, Feb 10, 2009 at 1:29 PM, Dave Salt <[email protected]> wrote:
> I'm trying to help someone create a process that will automatically submit > several jobs at a time. For example, it might submit 20 jobs right after > each other, with only a fraction of a second between each job. It's very > important that the jobs execute in the same sequence in which they were > submitted. For example, if the automated process submits jobs AAA, BBB and > CCC, then job AAA must finish executing before job BBB begins to execute > (and so on). > > I was under the impression that I could force jobs to execute in the > desired sequence by simply using the same job card for each job. For > example, if every job began with this job card: > > //useridX JOB > > Then all of the submitted jobs would have the same job letter (i.e. 'X'). > As far as I know this means only one of the jobs would execute at a time. > What I'm less sure of is that job AAA would be guaranteed to start executing > before job BBB? For example, if job AAA is submitted a fraction of a second > before job BBB, and both jobs have the jobcard shown above, is it guaranteed > that job AAA will start executing first? If it's NOT guaranteed, is there > some way to force the jobs to execute in the same sequence as they were > submitted? > > Note that: > > 1) It doesn't matter if job AAA is successful or not. All I want is to > ensure that job BBB doesn't start executing until job AAA has finished. > > 2) It would be difficult to combine the jobs into a single job; i.e. it is > preferable to submit each job separately. > > 3) These are not production jobs; i.e. they are jobs being submitted on an > irregular basis by a user. The user does not have access to any kind of job > scheduler. > > Thanks in advance for any suggestions! > I think it's a fairly common practice that there be a specific JOB CLASS that has only 1 initiator, thereby guaranteeing serial execution. Another idea is to submit all the jobs in hold status, and each job has as it's final step, a job step that releases the next job. That way you can also control what gets executed in the event of a job not working properly. i.e. if job 10 of 20 has a problem, it won't release the next job, giving you the opportunity to fix things. ---------------------------------------------------------------------- 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
