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.

Greg Stigers

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