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
mentioned before, the Workload manager involves processes within arbitrary
groups, over and beyond Job Queues.  Thus I don't accept the suggestions
involving various queues and attributes based on "Session, User.Account,
Group" instances.
 
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.
 
3)  Mohan replied to my earlier comments:
>> >SHOWJOB output:
> > >--------------
> > [snip...]
> > >:showjob ;format=jobq
> > >                               New field
> > >                               ~~~~~~~~~
> > >JOBNUM  STATE IPRI JIN  JLIST  JOBQ      INTRODUCED  JOB NAME
> > >
> > >#J3     EXEC        10S LP     SYSJOBQ   WED 11:46A  FTPMON,FTP.SYS
> > >#J7     EXEC        10S LP     SYSMGRQ   WED  5:47P  EMG,MGR.SYSMGR
> > >#S81    EXEC        34  34     SESSION   THU 12:17P  MGR.GOPI
> >                      ^^^
> > Why not change JIN to show the QUEUE name for JOBS? Cost is probably 4
> > extra characters, and no special formats needed.
>
>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.
 
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!).
 
 
Cheers.
----
Jim "seMPEr" Wowchuk
Vanguard Computer Services     Internet:    [log in to unmask]
 _--_|\                        Compu$erve:  100036,106
/      \                       Post:        PO Box 18, North Ryde, NSW 2113
\.--.__/ <---Sydney NSW        Phone:       +61 (2) 888-9688
      v      Australia         Fax:         +61 (2) 888-3056