On Wed, 10 Jan 1996, Mohan Das wrote:
> One of the underlying assumptions behind this proposal was that
> users/system administrators would not want to change all (or most) of
> the job scripts on their system to take advantage of the new
> feature. We wanted to provide a way of controlling the jobs on the
> system in a better way than is possible today, without having to
> change all the job scripts and UDC's. We need feedback from the
> customers whether this assumption is correct in the first place.
 
We run mostly 3rd party software in our shop.  It isn't feasible for
us to mass modify jobs each and every time we put up a new release
of an application.  Maybe these aren't really mutually exclusive
options, but the most important aspect is ease of implementation
and use.  To that end, I agree with this assumption.
 
> But with this assumption, the option of specifying the Queue name in
> either :JOB or :STREAM command was ruled out, since that involves
> changing the job files. Hence, we needed somehow to map each job to a
> queue, and user.acct seemed the best way to do this.
 
As I stated in an earlier post, USER.ACCOUNT is not flexible enough.
I don't see any reason why this can't be expanded to be:
 
   JOB_SESS_NAME,USER.ACCOUNT,LOGON_GROUP
 
> Now comes the issue of how to make this mapping known to the system. We
> considered 3 options:
>
> 1. The file method described in the proposal
> 2. Through :NEWQUEUE, :ALTQUEUE commands
> 3. Through :NEWUSER, :ALTUSER commands
>
> (3) was ruled out because we thought system administrators may not want
> to do this for thousands of existing users. Again, this may be a valid
> assumption, or it may be not. We need feedback on that.
 
Valid as far as I'm concerned.  Even without adopting the initial fields
to assign queues, this would be a lot of manual overhead.
 
> Apart from having to change the existing jobs, there is another
> drawback to this approach of explicitly specifying the queue name in
> the :JOB or :STREAM command. That is the following:
>
> Suppose a system has 3 queues, 1 for Long jobs, 1 for short jobs and 1
> default queue. Now, all the jobs have been hardcoded with the queuename
> that they should go into. But suppose, the system administrator feels
> that 3 queues are not enough and they need more granularity in terms
> of job sizes and decides to create 2 more queues. Then all the jobs
> which could be scattered all over the system need to be changed to
> take advantage of these 2 new queues.
 
Another very valid point.
 
> But, if we rule out explicit
> specification of queue in the initiation command (since too many jobs
> may need to be changed), the next best approach available is to map
> user.acct to queues, in my opinion.
 
See note above.  I can't stress enough how inadequate USER.ACCOUNT is to
assingning job queues.
 
>>> Each  user can be a  memeber  of only one Q at any point of time.  Users
>>> without any specified Q membership will belong to the general SYSJOBQ by
>>> default. If any Q is deleted,  all the  members of that queue lose their
>>> membership and will belong to the general job queue.
>>
>> Buzzz. Sorry, this is completely useless.  Nobody that I know would want to
>> run their system this way.  What I want is the ability to have different jobs
>> from the same user submitted to different queues.  We will happily go change
>> the !JOB records to have a ;QUEUE=LONGJOB (or ;INQUEUE= or whatever) option
>> on them.  Having a single user only able to submit jobs to a single queue
>> does not solve any problems.
>
> We need to know if all the customers feel the same way about being
> able to change job files. But we thought it may not be the case. Will
> need input there.
 
My take on queues is that it is suppose to make Operations easier.  In
fact, it automates a portion of what a Computer Operator does now.
Limiting a user to only one queue does not accomplish the task of easing
operations -- it gives us more inadequate structure.
 
What ever criteria is used must be able to evaluate down to a single
job queue so that the job can launch.  The suggestion I made in an
earlier post was:
 
    JOB_SESS_NAME,USER.ACCOUNT,LOGON_GROUP
 
If the following queues are defined:
   1)  @8000@,BATCH.ADV,@           2) @,BATCH.ADV,RETAIL
   3)  @,BATCH.ADV,CLASS            4) @,PGMR.@,@TEST@
   5)  JADVTICK,BATCH.ADV,RETAIL
 
Then jobs should be evaluated against the most specific definitions
first and fall through until a match is found.
 
   JADVTICK,BATCH.ADV,CLASS would fall into queue 3
   JRPT8000,BATCH.ADV,RETAIL qualifies for both queue 1 and 2 but
                             should be assigned to queue 1 since
                             it is the most specific definition.
   JSTMT,BATCH.GLEDGER,DATA doesn't match any queues - assign to default
 
>>> 3. Job limit - Maximum number of active jobs for this queue.
>>
>> This is really the only attibute that a QUEUE needs.  Most of the other
>> issues that could have been addressed here have been solved with the
>> Workload Manager product.
>
> True.
 
I really believe that the JOBFENCE is a valid setting for each queue.
 
>>
>> Ok, but let *us* tell you what queue we want it in.  It would however be
>> nice to be able to associate a default queue with each user, which can be
>> done with :ALTUSER ;JOBQUEUE=COMPILE
>
> Fair enough. We just need to know if everyone feels the same way.
 
This is possible using my suggestion above and doesn't require all the
extra administrative overhead of ALTUSER commands.
 
 
Regards,
 
--- John Joerger  ([log in to unmask])  ---  Press-Telegram (Long Beach)