Someone replied to me privately to the effect that the example I have seems
to be ready for multiple job queues.

Well, I did write:
> Come January, I want to create a single-job queue. In the mean time,
> I will probably rewrite some jobs to
> STREAM SOMEJOBA.GROUP
> PAUSE JOB=!HPLASTJOB
> STREAM SOMEJOBB.GROUP
> PAUSE JOB=!HPLASTJOB

Is there any conceivable reason * not * to implement a SINGLEQ that allows
only one job? Do we risk anything, anything at all, doing this? No reboot
required, right? I do need to read up on the job queues (less-than-obvious
URLs welcome). The only issues I can think of are resource utilization
(which I assume to be minimal), adjusting limits where and how needed, and
of course the herculean task of editing those few jobs that must run
exclusively. OK, one other issue just now occurs to me: jobs that do not
themselves run exclusively, but which should not run while other
single-threaded jobs are running. I have in mind here our database
reindexing and reorg jobs. At this point, am I back to resetting job limits,
or having some other job pause while these execute?

There is always the option to use a job scheduler to manage jobs as events,
but that's another thread for later.

Greg Stigers

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