🚀 go-pugleaf

Tom O'Toole (ecf_stbo@jhuvms.hcf.jhu.edu) writes:

>Pekka.Savolainen@Salcom.Fi writes...
>>Included, please find sys$examples:bind_read_me.txt
>
>I'm curious if anyone has explored the license implications of this.

YES!  We have.  Now, although I haven't looked in the solution provided by
Pekka, I did look into this technology quite a lot back in earlier versions
of VMS (T5.2 and some before this.)  My thought was to be able to restrict
CPU-hogging batch jobs to a subset of the available CPUs, thus providing
better response time to the interactive users.   (See, we could raise QUANTUM
up (good for a vector CPU) and not feel the effects of multiple batch jobs
so much.)  Anyway, VMS Engineering kept changing the scheduler on me, so
we waited until the activity died down.   (At one point, I was given
information on how to call a system routine to restrict a process to a
CPU.  It only crashed the system.  I didn't use that routine after that.) :)

Now that this seems fairly stable (we are at V5.5-1), we are using this to
our advantage.  Specifically, we had an 6000-420 which we wanted to upgrade
to a 6000-440.  The vendors of S1032 (I don't remember their name) wanted
big bucks for a new license.  We worked out a deal where we restrict the
users of S1032 to a single CPU, and now we can move S1032 from (I believe)
a 6000-420 up to a 6000-530 with no additional charge.

How did we implement this?  First, we restrict access to the S1032 files
and images.  In order to run S1032, you first invoke a set up procedure
which: 1) raises your base priority to 5, 2) restricts you to a subset of
the available CPUs, and 3) grants you the identifiers needed to run S1032.

The priority 5 business help ensure that these users get scheduled "fairly".
(Otherwise, they would only get to run 50% of the time.  2 out of 4 CPUs.)
Since they can only run on 2 of the 4 CPUs, the priority 4 users don't feel
much of an impact.  Note: the non-S1032 users may be scheduled on ANY
available CPU.

Questions?  Comments?  Flames?  Anyone read this far?   :)

-Derek S. Haining
 University Computing Services
 University of Washington
 Seattle, Washington  98195
 (206) 543-5579

 DEREK@MAX.BITNET
 DEREK@MAX.U.WASHINGTON.EDU