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.