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.