HP3000-L Archives

January 1996, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Mike Paivinen <[log in to unmask]>
Reply To:
Mike Paivinen <[log in to unmask]>
Date:
Wed, 10 Jan 1996 22:59:42 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (79 lines)
Mohan Das ([log in to unmask]) wrote:
: Hi,
 
: Thanks to everyone who responded to the proposal. All your inputs are
: highly appreciated.
 
: I will be replying to all the mails separately, but I would like to make
: some general observations here.
 
: 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.
 
This paragraph justifies the need for defining a default queue
per user.  You don't need to restrict a user to using that queue in order
to accomplish the stated goal.  You and Gavin agree on the need for
this feature.
 
: 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.
 
This is an additional feature over and above the need for defining
a default queue per user.  This feature allows a user to override their
default.  Again, I don't see much value in a multiple job queue system
that doesn't allow a user to select in which queue their job is going
to execute.
 
: 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.
 
The mental work required for all three approaches is the same.  You have to
determine which queues you want to define and which users you want to default
into which queues.  I see very little difference in the number of keystokes
you have to type to accomplish the defined task using method 1, 2, or 3.
In method (1) and (2), you have a little bit of a shorthand because you can
make a file entry like:
 
    SYSOPQ:  [log in to unmask],[log in to unmask]
 
or enter the command:
 
    NEWQUEUE SYSOPQ;[log in to unmask],u1.a2,[log in to unmask]
 
But method 3 isn't that much more complicated, you have to enter 3 commands
instead of 1:
 
    ALTUSER @.A1;JOBQ=SYSOPQ
    ALTUSER U1.A2;JOBQ=SYSOPQ
    ALTUSER [log in to unmask];JOBQ=SYSOPQ
 
In method 1, you have the additional tasks of remembering which file is
your job queue definition file and remembering to type INITJOBQS.  I think
a little task scenario analysis would make it clear which of these three
methods will work best for users.
 
Mike P.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mike Paivinen
[log in to unmask]
 
Hewlett-Packard
CSY - Mailstop 47UP
19447 Pruneridge Avenue
Cupertino, CA   95014

ATOM RSS1 RSS2