I've been reading through this thread and for the most part all of the ideas
are good ones depending
on how your shop operates. So far the 2 suggestions that have caught my
attention are:
1. Allow for queue to be specified as a user and/or an account attribute
(maintained obviously
via the ALTUSER/NEWUSER and/or ALTACCT/NEWACCT commands).
2. Allow for queue to be specified as a job stream parameter simular to ;PRI=
but with the option
to specify parameter with the :STREAM command as well.
As far as I am concerned, both of these are excellent ideas. I would like to
offer the following
idea for debate...
Rather than retrofiting user/account structures to allow for a queue or
multiple queues to be
maintained, how about creating a new structure much like workgroups. The
structure would be
maintained by it's own set of commands (much like SHOWWG, NEWWG and ALTWG).
The struture would
allow for queues to be defined by job/session name, user name, account name or
any combination of
the three. For instance:
PAYROLL job queue could contain users such as @.PAYROLL, PAYROLL.@, and
PAYROLL,@.@
Now you might have noticed that I did not say job name above but said
job/session name. This is
because I feel it is a good idea to allow for session queing as well. For
instance:
PAYROLL_AUDITOR session queue could contain the user @,AUDITOR.PAYROLL
PAYROLL_USERS session queue could contain the users @,@.PAYROLL
This way you could set the PAYROLL_USERS limit to 0, but still allow the
auditor to signon without
requiring the auditor to have OP so that he/she can signon with ;HIPRI.
Any user could signon to any queue for which he/she is authorized. It would
also follow that since
I user could qualify for multiple queues that a default queue could be
configured as the default
queue for the users specified. Here is a simple example of the QUEUE
configuration file I am
proposing:
PREFERENCE DETAIL
JOB PAYROLL @,@.PAYROLL;DEFAULT @,PAYROLL.@ PAYROLL,@.@;DEFAULT
;LIMIT=10
SESS PAYROLL_AUDITOR @,AUDITOR.PAYROLL;DEFAULT ;LIMIT=1
SESS PAYROLL_USERS @,@.PAYROLL;DEFAULT ;LIMIT=5
Most of this more or less is self-explanitor except for the PREFERENCE line at
the begining. The
purpose of this line is to tell the operating system how to determine which
queue to use if a user
qualifies for more than 1 default queue. In the above example, AUDITOR.PAYROLL
qualifies for both
PAYROLL_AUDITOR and PAYROLL_USERS. The PREFERENCE DETAIL tells the OS to use
the most detailed
definition first, in this case it would be the PAYROLL_AUDITOR queue. Another
option might be
PREFERENCE FIRST in which case it would be the first queue that the user
qualifies first. As a
matter of fact, if DETAIL is specified and there are 2 simularly detailed
definitions, the first
definition would be used.
Now, please keep in mind that this is a *VERY* rough concept and still needs a
lot of work, but
since everyone was giving such creative feedback, I thought I would post this.
Thank you for your time and patience....BTW, please forgive any/all gramatic
and/or spelling
mistakes :)
-------------------------------------------------------------------
Michael P. Smith [log in to unmask]
HP Systems Programmer [log in to unmask]
Hertz Corporation, Oklahoma City, OK
-------------------------------------------------------------------
'Be a team player, it diffuses the blame' - Dilbert
-------------------------------------------------------------------
The views and opinions expressed in this document are expressly
my own. So get off the couch, I obviously need more help than you.
|
