With respect to the default queue membership issues:
 
I think everyone agrees that we need some option equivalent to ;QUEUE=
on both !JOB and :STREAM, with :STREAM probably overriding !JOB.  It
looks like most people would like some way of configuring a default
queue membership so that they can take the maximum benefit from this
enhancement without modifying lots of JCL.
 
There is also the backwards compatibility issue of wanting to :STREAM a
job containing ;QUEUE= on a pre-multiq system (there are some really
kludgy ways of making the new syntax for !JOB backwards compatible, but
you *really* don't want to know what they are :-).
 
So, for specifying a default JOB -> QUEUE mapping, there are various
options, most of which have been suggested by someone here:
 
1) HP's original suggestion of a file mapping USER.ACCOUNT (possibly
with *arbitrary* wildcards) to a queue name.
 
2) :ALTUSER <username>;DEFAULTJOBQ= where <username> might be enhanced
to support wildcarded user names for ease of maintenance.
 
3) :ALTACCT <acctname>;DEFAULTJOBQ=
 
4) A combination of both 3 and 4.
 
5) Something more complex that will address JSNAME and possibly other
attributes of the job.  One example given was the possibility of this
being sufficient to replace simple usage of a third-party scheduling
package.
 
6) My suggestion of a user-written program to build functionality like
#1 and #5 on top of the basic facility and :ALTJOB;QUEUE=
 
7) AIFs designed to allow implementation of #6 in a cleaner manner than
programatic :SHOWJOB commands to a file followed by programatic :ALTJOBs.
 
8) (anyone have any other ideas?)
 
I like #4 because it gives you a reasonable amount of functionality without
introducing a new config file to worry about.  The information about a
user's default job queue is stored along with all the rest of that user's
information: in the directory entry (actually the used id database I guess),
Also if there is room in the ACCOUNT directory for an account-wide default,
then that lets people easily separate different application's job queues if
they run out of different accounts.
 
#1 seems to be too limiting for a lot of people, which leads us to #5, a
request for a more comprehensive version of the same thing.  #1 could
easily be extended to include the job/session name, which is probably
as far as this project can go towards being a complete Job Scheduler
Package.  Beyond this there are going to be too many arguments about
what should be part of the selection criteria, and there would probably
be few that would be used by more than a small number of customers at
best.
 
So, if we want a config file it probably looks something like:
 
ARAGE,MGR.PROD = ARJOBQ
AP@,[log in to unmask] = APJOBS
COMPILE,@.@ = COMPILE
CJ@,@.DEV = COMPILE
JOB.PROD = PRODJOBS
@.PROD = ADHOC
 
where each entry is [JSNAME,]USERNAME.ACCOUNT with full wildcards allowed.
When a job is submitted, and no overriding ;QUEUE= option is specified,
the config file records would be tried, in order, one-by-one, until a
match is found.  If no match is found, the job goes into the system default
queue.  By specifying more specific usernamesets earlier in the file, you
can have more specific associations that override more general ones and so
on.  You could potentially end the file with:
 
@.@ = NOJOBQ
 
Which would either prevent the job from being streamed, or dump it in a
zero limit queue (depending on the implementation) assuming 'NOJOBQ' has
not been configured (there is nothing special about the name 'NOJOBQ').
I'm not sure why anyone would do this, but it would be possible anyway.
 
This kind of config file, plus !JOB;QUEUE= and :STREAM;QUEUE= addresses
virtually all of the requests I have seen.
 
The downsides to having this config file are that it is a non-standard
thing compared to the rest of the way MPE is operated (though it is
exactly the way unix would do it, and we already have files like
RESLVCONF.NET.SYS that work this way).  It also increases the complexity
of the implementation a bit if :STREAM or JOB.PUB.SYS has to open this
file and read it every time a job is submitted.  There are issues about
how changes to this file are made.  If changes don't immediately take
effect (HP's suggestion) then you have no way of determining what the
current configuration is, since you don't know if the file has been
changed or not (providing a set of AIFs to retreive the current state
is an expensive alternative).  On the other hand, if the file is opened
and read each time, what happens if the file becomes unavailable (the user
is KEEPing a new version just as a job is streamed.
 
If the config file is included, I think its use (and its very existence)
should be optional, so that people who don't need this complexity don't
have to pay the maintenance and performance(?) penalties.
 
#6 and #7 eliminate the problem by leaving it up to the customer or 3rd
party to implement this functionality, albeit at a cost of performance
and annoyance to the customer :-). #6 is the cheapest since it requires
HP to do no work at all.  #7 may require as much work as #5, or it may
be something HP would decide to do anyway to update the OSAIF routines
that exist today.  It's the cleanest solution from the changes-to-MPE
point of view, but the messiest from most of the customer's points of
view.
 
G.