Has anybody noticed that Kim is kinda S-L-O-W sometimes? This is actually due
to a couple of things: one is that that you guys are using Kim to do lots of
hard work (this is good, keep it up). The other is that VMS 4 and its
associated processes gobble up about 2Mb of memory out of an available total of
4. This is about 1000 pages more than under VMS 3 (once again proves that
software grows to fill the available space) and as a consequence, programs
running on Kim do a lot more page faulting. What's even worse is that most of
these additional page faults are "hard" in that they are resolved by disk
accesses. There is (or will be shortly) a document called DOK:PAGES.DOC that
describes in some detail how VMS manages its memory. Read it if you're
intrested. 

In the meantime you can take it on blind faith that Kim needs more memory to
reduce these page fault rates, which in turn will make it run faster. There are
two ways to achieve this goal, one by hardware and one by software. The
hardware solution costs about $40k (buy more memory) and there's no chance of
gettin that kind of money. The software solution is to reduce the demand on
Kim's memory. One can achieve this by restricting access (boo-hiss), kicking
off users (blech) or by having the users help VMS manage its memory. Its this
last method that I want to try so I've written up a little program to do just
that. You guys have to help out by getting into the habit of running this
program yourself. I've tried to make it as easy as possible for you to do this
by setting up all the VT100 type terminals for "applications keypad" and
defining the keypad 0 key to "RUN SLEEP". All you have to do is press the 0 key
on the keypad if you expect not to be doing any work at your terminal for
anywhere from a few seconds to several hours. To wake up your terminal again,
just type any key which can if fact be the first character of your next
command. For the blue box development system people, DOWNC automatically chains
to SLEEP at program termination. (For all those who have already defined their
keypad 0 key to mean something else, sorry about that, your definition wins so
you'll have to define some other key sequence to SLEEP. You can require that
your password be entered to "wake up" your terminal by running SLEEPWP which
is done easily by pressing the PF1 (gold) followed by the 0 key.

Please understand that you're not giving up anything in either performance or
functionality in doing this, it only improves system performance for everyone
by allowing programs to use more memory TEMPORARILY. You get back all the pages
you freed up (plus more if you need them) as soon as you "wake up". You may
think "Why should I give my pages? I want to keep them all!" Actually, if the
system gets real busy, it'll take ALL your pages away from you whether you are
sleeping or not. It is NOT possible to hoard pages. But by sleeping, you
volunteer your pages for somebody else saving the system the trouble of being
sneaky about taking them from you. Also, don't expect Kim to suddenly get 10
times faster. I realistically expect that it will change from S----L----O----W
to a mere S---L---O---W, but every little bit helps in this case.

As an added bonus, ZAP_THE_USER will leave your process alone if you are
running sleep and the process(es) sleeping with password won't get zapped at
23:30. You can use sleep with password in lieu of logging out, which makes
logging back in as fast as just typing your password. But please don't sleep
with password on public terminals since it will prevent users who don't know
your password from using them. You will notice that Sleep says who it's waiting
for, so if you inadvertantly lock up, say the VT100 in the DIO room, you will
surely be hunted down and set upon by an angry mob of users. Should you
find that you've done such a foul deed, SUICIDE from any other terminal will
quickly solve the problem. Lucky for us so far, we can correct such breaches of
honor by comitting SUICIDE with a few keystrokes at our terminal instead of the
more conventional everlasting method requiring the use of a blade.