On Fri, 19 May 2000 13:23:25 -0700, Bruce Toback <[log in to unmask]> wrote:

>Randy Keefer writes:
>
>>I propose
>>the following:
>>
>>CQ = 152,255        DQ = 190,250         EQ = 150,151
>>
>>How it works is very simple.  Your user community and developers/operators
>>logon into the CQ.  ....  Developers are bad, because they
>>compile online and execute large serial queries of databases and files.
>>They can suck up alot of CPU.  This can affect your onlines users some,
but
>>can stop batch jobs (in the DQ) in their tracks.  Using the above scheme,
>>any online process in the CQ that uses vast amounts of CPU will quickly
drop
>>their queue value to 255.  Batch jobs in the DQ run between 190 and 250.
>>Thus, batch jobs will have a slight edge over these "bad online users".
>>...The EQ is
>>tuned so that it has priority over all online and batch users, therefore,
if
>>a crisis arrises, the System Manager will have a prompt that receives time
>>right away.  The EQ can also be used when a batch job needs to be "rushed"
>>through.
>
>The problem with this method is that "bad" users -- by which I assume you
>mean malicious, since the normal set of queues allows anyone to run at a
>lower priority (higher numerical value) than the default -- can simply do
>everything in the ES queue. All of MPE's process security structure
>assumes CS <= DS <= ES (numerical). Thus the :JOBPRI command can be used
>to restrict jobs from running in the CS queue, but won't prevent jobs
>from running in ES. Similarly, programs like QEDIT, which allow
>specifying the priority of subtasks, have security that assumes it's OK
>if the user requests the ES queue.
>
>If some of your users are truly malicious, this scheme makes it easy to
>put their work ahead of other users'.
>
>-- Bruce
>
Yes, you are correct.  If developers know about the queue arangement, they
can log into the EQ, if you let them.  I instituted a UDC that prevented
them unless they are on an approved list.  Also, Security/3000 can restrict
a user to a specific queue.  And if all else fails, then that is where your
management skills and means of gentle persuation come in.

By the way, what I mean by "bad" online users is those users (usually
developers) who run lengthy processes online instead of putting them into
batch jobs, where they belong.  Any process that takes more than one minute
of CPU time (not real time) should be in a batch job, unless it is very high
priority.  Program compiles, adhoc reports, serial queries, etc. can all
drain time from your user community and can completely stop batch jobs, if
they are executed in the CQ using the system defaults.  By changing the
queues, if the user runs these processes, then they are sent to the "back of
the bus" and fall behind all users.  In fact, my scheme rewards the online
developer if he/she puts their work into a batch job.

Randy Keefer, Consultant