On Jan 10,  3:20pm, [log in to unmask] wrote:
> Subject: Re: Multiple Job Queues
snip...
 
>
> In many cases I think people *will* want to go change all their job
> stream files to include ;QUEUE= (or whatever it is called).  The new
> level of control granted by this feature will be enough to justify
> whatever effort is involved.  Even this type of customer will probably
> only change a limited number of job streams.  The majority will
> probably still use the default system queue, and only the exceptions
> will need to be edited.
 
Probably true.  Implication is that we do need to have a limit on the system
default jobQ, separate from the other jobQs.  Perhaps the default value for
the limit on the system jobQ should be the job limit specified in the :LIMIT
command?  That is, the default sysjobQ limit equals the global job limit.
This is compatible to prior uses of LIMIT, but could be changed via
:altjobq $sysjobQ;limit=X   or  :limit X ;jobq=$sysjobQ.
 
snip...
>
> By the way, in HP's proposal, If user A.B streams a job that logs on
> as X.Y, which user is the one that determines which queue the job
> goes in?  Of the people who like the idea of the users->queues mapping,
> I'll bet that half would like it to be one way, and the other half
> would like it the other way.
 
My vote is the default jobQ membership is based on the user.account in the
:JOB command.  Thus, a single JCL file could introduce jobs into different
jobQs.  This assumes that user.acct is a sufficient default jobQ membership
criteria.  If user.acct alone (no jobname, no group name) is not sufficient
then we should not extend NEW/ALTACCT and NEW/ALTUSER to support a jobQ=
parm.  Instead, we would need to use some config file, or make default
membership an explicit jobQ property, e.g.:
   :NEWJOBQ xxx;defmembers="jobname,usr.acct,group; @.acct; j@,usr1.sys;
etc..."
 
 
Jeff Vance
 
--