Mohan writes:
> The new proposal has quite a few changes from its predecessor, most of
> these changes based on what we heard from you.
 
Overall, I'm quite happy with the new proposal.  I just have a few
comments:
 
> One of the major changes is in mapping the users to job queues.
 
I could live without the mapping, though a default queue specified in
:NEWUSER / :ALTUSER (and account wide defaults with :NEWACCT / :ALTACCT)
would still be nice.
 
>    b. Don't have any global limit. Each Q to have its own limit.
 
I prefer to see it this way for all the reasons stated earlier.
 
> Another issue on which there was some discussion was that of
> restricting users from streaming a job into any queue.
 
The ACD idea sounds like a good one.  I second the suggestion that
the HPSPOOL files be created in a greoup other than 'IN' to avoid
confusion (probably JOBQ.HPSPOOL).
 
Does this mean that the system default jobq will have a name so we
can alter it's ACD, thus preventing some users from streaming jobs at
all?  If it will have a name, I vote for something logical like
'DEFAULT' which makes more sense if you must have a special case
than something like 'HPJOBQ', since $DEFAULT won't work as an MPE
(or Posix for that matter) filename. '_DEFAULT' would be an option
too I suppose.
 
I suggest that it may now make sense to check BOTH the USER.ACCOUNT
of the user executing the :STREAM job *and* the USER.ACCOUNT that the
job is logging on as against the ACD.  The job's login could be
compared against the 'eXecute' access, and the :STREAMing user's login
could be checked against something else (R, W, etc.).  With this
extension I can say that I don't want any jobs logging on as COMPILE.DEV
into the BIGLIMIT queue, *and* I get the ability to say that I don't
want the user DOOFUS.IDIOTS to be able to stream *any* jobs, regardless
of how they log on (or maybe only into the NOLIMIT queue :-).
 
> Each queue will have an associated permanent file in IN.HPSPOOL. The file
> name will be same as the Queue name. This file will be created along with
> the queue when NEWJOBQ is executed and is purged when the queue is deleted
> using PURGEJOBQ command (explained later).
 
So it will be the existance of this file that determines whether the
queue is 'real' or not?  What happens if someone :PURGEs this file?  You
may not be able to prevent this, so you should handle it gracefully.
What is the life expectancy of a queue?  Do they survive system restarts?
SLT/INSTALLs?  If they survive restarts, does the limit reset to zero on
reboot?  It sounds as though SYSSTART would have to contain three
commands for each queue:
 
:CONTINUE
:NEWJOBQ myqueue
:LIMIT <n>;JOBQ=myqueue
 
just because you could never be sure whether the queue existed.
 
> Jobs waiting or executing in a queue can be moved to other queues by SM/OP
> :altjob ;jobq=<qname>. When an executing job is moved, the limit of the
> target queue is ignored and the job continues to execute in the new queue.
> A waiting job continues to wait in the new queue if the queue has already
> reached its limit.
 
Good.
 
>    Limit is the only Q controlling property and it can be changed by
>    :limit [+-]n;jobq=<qname> command.  Qname and INPRI are attributes
>    of a Q.  The queue is sorted by INPRI first, then by INTRO time.
 
Just a nit but :LIMIT +1 is currently valid and today means set the limit
to 1.  There could be some dumb program in the world that does this today.
 
>    PURGEJOBQ qname
 
>    The file corresponding to the queue will be deleted, provided there
>    are no jobs waiting in the queue. If there are waiting jobs, queue
>    won't be purged. The default system job queue can not be purged.
>    Only users with SM/OP capability can execute this command.
 
You'll handle the race condition of someone :STREAMing at the same time
their jobq is being purged of course.  What happens if a user tries to
stream into a non-existant queue?  I assume the :STREAM fails with an
appropriate error.  What error(s) will be returned if the ACD security
check(s) fail(s)?
 
> :showjob ;format=jobq
>                           New field
>                           ~~~~~~~~~
> JOBNUM  STATE IPRI JLIST  JOBQ      INTRODUCED  JOB NAME
>
> #J3     EXEC       LP     HPJOBQ    WED 11:46A  FTPMON,FTP.SYS
> #J7     EXEC       LP     SYSMGRQ   WED  5:47P  EMG,MGR.SYSMGR
> #S81    EXEC       34     SESSION   THU 12:17P  MGR.GOPI
 
Once again I think the default job queue and the session 'queue' should
display as blank spaces to avoid cluttering the display and making it
difficult to pick out the exceptions.
 
Something has to let us see what jobqs exist, and what their :LIMIT values
are, and I would assume that this would be :SHOWJOB.  Something like the
way :SHOWOUT shows per-device outfence values perhaps?
 
G.