In <[log in to unmask]> [log in to unmask] writes:
 
> We in CSY Lab are investigating  the feasibility of providing  Multiple Job
> Accepting Queues on MPE/iX.  We are still in the preliminary  investigation
> stage and as yet, no decision has been taken to implement this enhancement.
> As  part  of  this   investigation,   we  would  like  to  know  customers'
> expectations and requirements regarding this feature.
 
Mohan (and group!);
 
  I'd first like to add my appreciation for the opportunity to provide
feedback on this potential feature. I've been one of the backers of this
enhancement for quite a while, and would like to throw in my $.02 in hopes
that it might provide another viewpoint and perhaps something to think
about.
 
  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}
 
  Where each directory under /HPSPOOL/IN would have the input spoolfiles
for waiting jobs which were put into that queue either by the ;JOBQ (or
whatever) parm on the !JOB card, or by overriding it with a ;JOBQ= on the
:STREAM command. Some advantages of this setup; by using the first two digits
/places of the directory name as a numeric sorting sequence, directories
could be searched in order for the next "job-in-line" - an order which can
be forced by the use of ordering the directories numerically. Also, the
directories could be subject to normal MPE/HFS access restrictions; so one
could add ACDs or other restrictions defining who could place jobs in which
queues.
  A .limit file (or somesuch) could be created in each directory with just
a two digit job limit for that queue (or additional parms if desired) with
defaults taking precedence if the file is removed.
  I like the idea of replacing the IN-dev in the showjob display with the
queue name, though it would have to be a non-default format since I'm sure
there are a lot of programs/command files depending on the showjob format
now. I also like the idea of a default queue for a user.account, but the
order of precedance should be:
 <default queue based on user.account in !job card>
 <jobq= parm on !job card>
 <jobq= parm on :STREAM command>
 <:ALTJOB ;jobq= specified by OP/SM>
 
Now, back to watching the snowplows! ;-)
 
 
______________________/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_
  Chris Bartram        Sales (US):   800 Net-Mail    Fax:+1 703 451-3720
   ______              -or-       +1 703 569-9189 E-Mail: [log in to unmask]
  /__ |  \__________   Sales (Europe):+44(0480)414131 Fax:+44(0480)414134
 /  / | / ________     Sales (Pacific Rim):+61 3 489 8216 (same for fax)
|  /_ |<  ______       Tech Support:+1 703 569-9189  Fax:+1 703 451-3720
 \ __)| \ ___          E-mail: [log in to unmask]   Personal(me): [log in to unmask]
  \______/ Associates  6901 Old Keene Mill Rd Suite 205 Springfield VA 22150
______________________/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_
Gopher: gopher.3k.com   Anon-FTP: ftp.3k.com  WWW: http://www.3k.com/