Subject: | |
From: | |
Reply To: | |
Date: | Tue, 13 Feb 1996 09:43:24 -0400 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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
|
|
|