HP3000-L Archives

February 1996, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jon Diercks <[log in to unmask]>
Reply To:
Jon Diercks <[log in to unmask]>
Date:
Tue, 13 Feb 1996 09:43:24 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (70 lines)
At 02:48 PM 2/13/96 +0500, Mohan Das wrote:
>One of the major changes is in mapping the users to job queues
> ... we have decided to drop this default mapping from the
>current proposal for the time being.
 
I can live with that.  Even our third-party stuff at least has hooks that
would allow us to add ;jobq parms where needed.
 
>Another issue which generated some discussion was that of Global limit
>vs. Local limit.
...
>
>   a. :LIMIT will change the global limit. :limit ;jobq=<qname> will change
>      Q limits.
>
>   b. Don't have any global limit. Each Q to have its own limit.
>
>We weighed the pros and cons of both the approaches and decided to go
>with the second approach.
 
I still feel pretty strongly that (a) would have been better, but if you do
go with (b) then please include a wildcard capability so that we can change
the limits of all queues at once, i.e. ":LIMIT 0;JOBQ=@".  We must have some
mechanism to shut out all new jobs, and :JOBFENCE isn't adequate because it
locks out sessions too.  Even the wildcarding isn't ideal, because then
we'll need to use a command file or some such to reset the queue limits to
their normal values, but I can probably live with that.
 
>Another issue on which there was some discussion was that of
>restricting users from streaming a job into any queue. ...
> ... We have decided to include restriction
>using the ACD mechanism.
 
Cool.
 
> Each queue will be a special file in
>IN.HPSPOOL and the permissions of this file determines who can stream
>jobs into that queue.
 
Keep in mind that this opens up the potential for name collisions if someone
happens to do a ":NEWJOBQ I1".  It might be worth having a separate group
like JOBQ.HPSPOOL explicitly for this purpose.
 
>SHOWJOB output:
>--------------
>
>:SHOWJOB command will have a new format parameter ;format=JOBQ which
>will indicate the queue name to which each job belongs.
>
>ex:
>
>: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
 
Let me echo the previous suggestion that the JOBQ field should be left blank
for sessions and for the default system jobq.  We are primarily interested
in seeing exceptions here, so the whitespace for 'normal' lines makes the
important ones easier to spot.
________________________________________________________
Jon Diercks * Programmer/Analyst      Computing Services
[log in to unmask] (PGP available)     Anderson University
http://rowlf.csv.anderson.edu/        1100 East Fifth St
(317)641-4305 * FAX (317)641-3851     Anderson, IN 46012

ATOM RSS1 RSS2