In <[log in to unmask]> [log in to unmask] writes:
 
>  >   Currently input spoolfiles are kept in IN.HPSPOOL (aka /HPSPOOL/IN). How
>  > about simply(?) using HFS and allowing the creation of a hierarchy of
>  > directories under /HPSPOOL/IN denoting additional input queues, perhaps
>  > something like:
>  >
>  >   /HPSPOOL/IN           {contains default input spoolfiles as today}
>  >   /HPSPOOL/IN/01MAINTQ  {contains input spoolfiles in MAINTQ queue}
>  >   /HPSPOOL/IN/01PAYROLLQ{ditto PAYROLLQ queue}
>  >   /HPSPOOL/IN/06DEV     {ditto DEV queue}
>  >   /HPSPOOL/IN/08LOWPRI  {ditto LOWPRI queue}
>
> I don't know if there will be any issues with the input spooler if we
> change it this way. Will have to consider. Good suggestion,
> nevertheless. But I didn't understand how those two digits came in ?
> Do they signify some relative priority among the queues or something ?
 
At some point if you have one available slot (for a job to logon) and two or
more jobs in different queues, you have to decide which job gets to start. By
prepending a two digit sequence in front of the queue name, you give all the
queues a defined priority, and make the job of picking the next job to launch
predictable and user-definable. (A single digit would probably suffice now
for the ranking/priority however.) You just go through the queue list til
you find a queue which matches one of the jobs in line.
 
Since all queues are directory names, it makes the job of searching them
relatively easy; a (sorted) directory list give you a list of all queues, and
copying or renaming queues becomes trivial.
 
Each directory can easily contain a "control" file containing the limit
(and jobfence/maxpri/defaultpri) settings for that queue (if the file doesn't
exist for some reason, the system queue defaults apply).
 
Let me add my vote to the ability to alter the "queue" of a job after it's
been launched; it makes management much easier in several situations I can
think of. It seems to me that a user's job is to get his job done as soon as
he can (i.e. it's not their job to learn the workings or queue management
policies of the system); it's the system management's responsibility to
allocate machine resources equitably - the queue process we're all describing
is a tool for the system manager (or operator tasked with the duty) to more
easily distribute the available machine(cpu) resources. This task is often
required after-the-fact (i.e. after a user has already gotten his/her job
into the 'mix', possibly [even often in some environments] without knowledge
or concern for queue 'policy'].
 
            Does this make $.04?
 
                 -Chris Bartram