Smart pause ?  Shovel all these jobs into a single-threaded job q ?  Toss in a
few 'jinfo's  & 'jobcnt's ??  Its hard to imagine that you can't do it somehow
with these tools.

For example, to have a job pause till  a job it streamed logs on:
!STREAM  MAILSTOP.REPORT.EMAIL
!PAUSE   2400;   JOB = !HPLASTJOB;  WAIT
(the 2400 is arbitrary, and much longer that I expect it to ever take)

And to have a job pause till the job that streamed it logs off:
!SETVAR STREAMED_BY     WORD(HPSTREAMEDBY,"()",2)
!PAUSE 14400;  JOB = !STREAMED_BY;  INTERVAL = 5

Those are working examples at our site.  For your case, maybe have the jobs
that stream other the other jobs try:
:STREAM A
:PAUSE 9999; JOB = !HPLASTJOB; INTERVAL = 5
:STREAM B
:PAUSE 9999; JOB = !HPLASTJOB; INTERVAL = 5

and / or have the 2nd job that streams other jobs try something like (not
tested)
if jobcnt ('firstjob-that-streams-other-jobs,user.acct', joblist_var)  > 0
    setvar x  word(joblist_var,,1)
    pause 9999; job = !x
endif


Dave Powell,   MMfab

----- Original Message -----
From: "Greg Stigers" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, April 22, 2005 14:16
Subject: [HP3000-L] separating sets of job streams


> We have a few jobs that stream other subordinate jobs, waiting for and
> validating each job before streaming the next subordinate. Currently, we
> rely on LIMIT and STREAM ;AT= to manage these jobstreaming jobs, streaming
> the second such job five minutes after the first. Inevitably, the first job
> will take more than five minutes, and the second job will begin streaming
> its jobs, before the first is finished, with less than desirable results.
> Remarkably, the larger design is not so ham-handed, such that simply
> combining two such jobs is not an effective solution. Creating yet another
> layer, an uber-stream to stream both jobstreaming jobs could work. The
> objection to that is that it complicates this further than two levels, and
> perhaps merely perpetuates a poor idea.
>
> So, is there some clever solution that only requires MPE? We do not have
> MPEX. We do not have a budget for solving this, and that does not mean that
> we can spend as much as we want. I can only spend time, within reason. We
> are evaluating MasterOp, and that may become our solution.
>
> Greg Stigers
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>

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