Maybe I'm reading too much into the exact wording of 'stream other subordinate
jobs, waiting for and
validating each job before streaming the next subordinate', but I don't think
just one jobq can do it.
I think the idea is job A streams A1, checks its results somehow, then repeats
for A2, A3, etc. Then job B streams and checks B1, B2, etc, etc. One job
queue wouldn't let A1 log on while A is still hanging around to check the
results. Maybe 2 job queues -- one for A & B and the other for A1 thru Z99,
etc ??
Dave Powell, MMfab.
----- Original Message -----
From: "John Clogg" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, April 22, 2005 16:03
Subject: Re: [HP3000-L] separating sets of job streams
Create a job queue with a limit of 1 (6.5 or later), and stream all the
jobs into that queue.
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf Of Greg Stigers
Sent: Friday, April 22, 2005 2:17 PM
To: [log in to unmask]
Subject: 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 *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
