Mohan writes:
> Thanks to everyone who responded to the proposal. All your inputs are
> highly appreciated.
Thank YOU for asking!
> 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.
>
> 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.
>
> 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.
I think you'll find that (3) is not that bad of an option. I'd rather
do 100 ALTUSERs than manually edit 100 lines in a config file. Of
course wildcards in the config file mean you don't really have to make
that many changes, but it's still completely different from the way
everything else in MPE works today. If you can :ALTACCT;DEFAULTQ=FOO
to provide a default for the account if no value is specified for the
user, then some people would not need to edit every user.
I think there are different ways that these new features will be used.
In some cases, jobs will all continue to be submitted to the system
default queue, but operations staff will use ALTJOB;QUEUE= to move
things around manually.
A varient on this would be a third-party tool that would do this for
the user. A very nice job scheduler could easily be constructed
that would operate by setting the system default queue limit to zero,
and it would periodically do a programatic showjob (it would be cool
if it could do ':SHOWJOB;SELEQ=[JOBQ=""];*filename' to select only
jobs in the default queue) and then based on the username, jobname,
etc., it would issue :ALTJOB commands to put the job into the
appropriate queue. This could be a very easy program to write. There
would probably be one or two freeware versions written, and the job
scheduler third-party products could add this functionality to their
products (I don't think the multiple job queue features are going to
replace Maestro, OCS's scheduler, and similar products for anyone).
This would allow the functionality of having a config file that
associates users to queues without burdening CSY and the MPE/iX
Kernel with another non-standard configuration file and all that
goes along with it.
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.
For a lot of users it will be a fairly simple matter to change menu
systems to add ;QUEUE= to :STREAM commands based on some attribute
of either the user streaming the job or the job being streamed. I
would expect 3rd-party security/menu providers (Vesoft etc.) to add
features like this.
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.
G.
|
