Jim Wowchuk writes:
 > At 11:40 AM 10/1/96 -0800, [log in to unmask] wrote:
 > >
 > >   :ALTJOBQ QUEUE=COMPILE;LIMIT=1;MINPRI=ES;MAXPRI=DS
 > >   :ALTJOBQ QUEUE=LONGJOB;LIMIT=2;OUTCLASS=LP4
 > >
 > >etc.  The problem is in determining where to stop in adding new parameters,
 > >since most of what you could do here is already addressed by the Workload
 > >Manager product.  Unfortunately, the Workload Manager is an add-on product
 > >that most people will not get, so there will be pressure to enhance the
 > >multiple job queue features to do Workload Manager stuff.  A virtually free
 > >option would be to bundle the Workload Manager into FOS and do a simple
 > >implementation for multiple job queues.
 >
 > Given that (IMHO) the job queue feature is the converse of output printer
 > spool queue, that is it is input spool queues (for the job dispatcher), I
 > offer a couple of comments:
 >
 > 1)  The features of INPRI, MINPRI, MAXPRI, OUTCLASS are properties of the
 > job itself, so should not involve Workload manager.  They determine when a
 > job gets started, where its output goes and what limits apply to that job,
 > regardless of who initiated the job, or what account it logs into.  As
 
Agreed that INPRI, MAXPRI etc. won't come under the Workload manager
domain.
 
 > 2)  Existing system-wide LIMIT, JOBFENCE, JOBPRI *should* become properties
 > of the job queue, which inherits the default of their respective system
 > values, just as OUTFENCE does now.  It would be pointless to have multiple
 > queues if they only had one overall LIMIT setting.  Being able to have only
 > one executing compile job at a time (in JOBQ COMPILE) with maybe 6 currently
 > executing in ACCOUNTS, and another 3 background jobs in LONGQ is where I see
 > the real benefit of this development.
 
LIMIT *is* a property of the queue, in the proposal which was
posted. Whether there is any real need for the other properties also
to be different over various queues is the question under debate. If
JOBFENCE, JOBPRI etc. need to be properties of the queues, we need to
know under what situations they will be useful. Please note that, I am
not questioning the usefulness of your suggested approach. Just asking
for some real-life situations where that feature will be useful.
 
 > 3)  Mohan replied to my earlier comments:
[snip]
 > >That could lead to compatibility problems with UDC's which might
 > >assume the current output format of :SHOWJOB.
 >
 > My point is: what value is JIN for batch jobs if all it ever shows is the
 > 10S? At least if it has the JOBQ there is some merit in its presence.  If
 > backward compatibility is the issue, then require the ";format=jobq" before
 > presenting it.
 
Ok, I thought you didn't want the new ;format=jobq parameter at
all. If it is only to combine JIN field and the proposed new JOBQ
field, it can be considered.
 
 > 4)  While the topic of this thread is "Job Queues" and thus a clear
 > understanding is present, later in practice the term
 >         !JOB ...;QUEUE=queuename
 > could be ambiguous.  There is both an input JOB Queue and an output $STDLIST
 > Print Queue (accessed by the OUTCLASS parameter).  Given there are at least
 > two different queues, perhaps the term should be JOBQ[UEUE]?  The suggested
 > syntax for the commands "ALTJOBQ QUEUE=quename;..." could perhaps become
 > "ALTJOBQ [JOBQ=]quename;..." (and NEWJOBQ!).
 
Good suggestion. Will keep in mind.
 
Cheers,
mohan
--
 ============================================================================
Mohan Das K S                                   email: [log in to unmask]
HP India Software Centre                        Phone: 91-80-225-1554 x218
29, Cunningham Road                             Telnet:     408-847-1026
Bangalore - 560 001 INDIA                       Voice Mail: 408-447-4329
 ============================================================================