In message <C6AD9A5B75B8D94B93E0D4258E82F88F7D9E11@port>, Kim Borgman
>Somewhere, some time back, someone on this list had a neat way to set up job
>streams from within another job.
>I need to have a user stream a job - A, and from within job-A, stream other
>jobs. Of course each job in job-A can't be streamed until the previous one
>is done. It was something like an "exists" command.... or a "wait"
>Example of job-A
>! 'exists' command
>! 'exists' command
>ie I want jar111 to get done before jar112 is streamed....
If these jobs are *only* run this way, why not stream jar112 from just
before the EOJ of jar111?
And what *exactly* do you mean by 'each job in job-A can't be streamed
until the previous one is done'? Does that mean that jar111 has to
*succeed* before jar112 can run, or is it just a case of letting go of a
The above 'exists' logic is only good for the latter case, while the
'cascade' approach supports the former. (But is a bummer if it's only a
resource thing, and jar111 fails, bringing the whole cascade down).
Another approach, if these jobs are only run from 'A' - or even if they
aren't, perhaps - might be to give them all their own dedicated
job-queue, job limit 1. Then you can let them all be streamed at once,
more or less, getting Job-A over very quickly, and letting MPE be your
one-at-a-time enforcer. Again, only works with 'resource' limiting,
rather than 'must succeed'.
Which is it here; why exactly, in this case, must the jobs run one at a
(And I have this problem, having inherited a system with pervasive
'dirty locking'; letting two jobs run together doesn't bear thinking
about. Whether run individually by users, or by a job-A, the approach we
use for the overnight processing. We use the 'JOBQ' approach to
Roy Brown 'Have nothing in your houses that you do not know to be
Kelmscott Ltd useful, or believe to be beautiful' Wm Morris
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *