Greg,

If I am reading this correctly, you can have several "main" jobs running
simultaneously. Each of these main jobs will stream several "sub" jobs.
It sounds like one rule you are trying to enforce is that subJobA2
should not start executing until subJobA1 completes successfully.

Your code below should work for that rule. You also need to realize that
the fragment "limit +1, pause, limit -1" is not autonomous across the
system. E.g. right after mainJob1 executes LIMIT +1 it can loose the CPU
to mainJob2 which then executes LIMIT +1. Now the limit is +2.  I still
think what you've written below will work, as long as there are no other
competing jobs outside of the job trees you're describing.

However, it also sounds like you want to enforce another rule, such as:
all of mainJob1's sub jobs need to complete before starting to execute
any of mainJob2's sub jobs.  If this is true then you have at least a
few choices:
1) you can stream mainJob2 after the last sub job in mainJob1
2) you can stream each main job in its own job queue (preferred, IMO)
3) you can add logic to mainJob2 to not stream its sub jobs if any
subJob1 is running. And similar logic for mainJob3...
4) if you don't do (3) you could add logic in the subJobN to not start
if there are any subJob(N-1) executing.

Of course, I may have mis-guessed the "second" rule which I think you
are seeking.

HTH anyway,
 Jeff Vance, vCSY

> Thanks for the replies. They offered some good ideas. But it 
> looks like I need to clarify what is happening to us. We have 
> two jobs that use PRI=10 in their job cards. The second is 
> streamed some minutes after the first. Both jobs are little 
> more than wrappers for streaming other jobs, with validation 
> logic built in appropriate to the job streamed. In fact, the 
> first has the following logic for each of its subordinate jobs:
> !STREAM SUBJOB1A.JOBSTRMS
> !PAUSE JOB=!HPLASTJOB;NOTEXIST
> !LIMIT +1
> !PAUSE JOB=!HPLASTJOB;EXIST
> !LIMIT -1
> !LISTSPF !HPLASTSPID;SELEQ=[JOBABORT=FALSE];DETAIL
> !IF CIERROR <> 0
> !   TELLOP !HPJOBNAME !HPLASTJOB failed; see !HPLASTSPID
> !   CONTINUE
> !   MAIL.COMMANDS '-t Operations !HPJOBNAME !HPLASTJOB failed; see
> !HPLASTSPID'
> !   ESCAPE
> !ENDIF
> 
> While the first job is waiting for one of its subordinate 
> jobs to finish (although this is not an issue if it is the 
> last of the jobs), the second job streams, and it streams its 
> first subordinate jobs, SUBJOB2A. That job then is in the 
> queue ahead of, say, SUBJOB1B or SUBJOB1C.
> 
> To further complicate the picture, we have more than two such 
> jobs, and they can occur in various combinations. We may 
> stream JOB2A and / or JOB3A after JOB1A, for three different 
> possible combinations for just those jobs. I have suggested 
> simply adding PAUSE JOB=JOB1A;EXIST as needed to said jobs, 
> but that has not been met with great enthusiasm.
> 
> I'm of the opinion that change is in the air, and we have to 
> decide what we regard as the least of several evils, where 
> the evil of loathsome change bestirs that most primal fear, 
> fear of the unknown. Something must change to make this 
> scheme work, so which change gives us the most benefit with 
> the least disruption? Our current means of job scheduling is 
> based on the mainframe-era assumption that the first job 
> should be allowed that amount of time to complete, 
> guaranteeing several minutes of idle time during 
> time=critical and business-critical processing, and 
> occasional failure when the first job runs longer than 
> someone guessed it might. But other than this, I have no 
> strong opinions on the subject.
> 

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *