GKN%OAK.SAINET.MFENET@LLL-MFE.ARPA (02/21/86)
From: <GKN%OAK.SAINET.MFENET@LLL-MFE.Arpa> (Gerard K. Newman)
Date: Fri, 21-FEB-1986 08:30 EST
To: Info-VAX@SRI-KL.Arpa
Message-ID: <[OAK.SAINET.MFENET].379DCCA0.008EADFE.GKN>
US-Mail: Science Applications; P.O. Box 2501; Oak Ridge, TN 37831
Telephone: (615) 482-9031 x293
X-VMS-Mail-To: INFO_VAX
From: Arpa%"AWalker@RED.RUTGERS.EDU" 21-FEB-1986 03:52
Subj: Malodorous microvax miscellany
Date: 20 Feb 86 06:31:10 EST
Message-ID: <12184841088.31.AWALKER@RED.RUTGERS.EDU>
First and foremost, *where* is the escape key on the bloody keyboard?
F11, as sometimes used on the VT220 and Vaxstation VS100 to send an
escape, insists on sending <esc>[23~, and there's no menu item on
these things to change it. Forever typing control-[ is a real pain in
the tail.
Correct me if I'm wrong, but F11 only behaves as an <ESC> when the terminal is
in VT100 mode. Another <ESC> key is ^3 on my VT220, which is still a pain in
the ass to type but I find it easier than ^[. Incidently, the Tops-10 people
have the right idea here. Under the monitor I'm field testing, there is a
command to remap any key into the <ESC> key. I usually map the ` character
to <ESC>...
Furthermore, the other keyboard control character mappings are all
screwed up -- ^@ sends a ^R, control-other-things send completely
unexpected things. Is there any way to change the keyboard handler's
interpretation of what ascii is??
I dunno about this. Somehow I doubt that DEC gives you the option of changing
what the keyboard sends. ^space isn't a null??
After I brought up Decnet on them [ethernet style], everything works
right except remote logins. Whether you do set host <nodename> from
outside or set host 0 from the microvax, the incoming connection is
broken before you even get to log in. Is the decnet stuff for the
microvax designed to do this? Set host/old, oddly enough, *does* work.
Check to make sure that REMACP was started correctly by STARTNET.COM. I've
also discovered that AUTOGEN on a microVAX loses pretty bad when it creates
your VMSIMAGES.DAT. Lots of images don't get installed with the privileges
they need. You say other stuff works, so that probably means you didn't
forget to install your DECnet key. Check to see 42 (CTERM) is defined and
has a PID next to it with NCP SHOW KNOWN OBJECTS. The PID should be that
of REMACP. I'm afraid that's not much help, but it's all I can think of
right off hand.
But this doesn't correctly do log files, which is one thing our group
wants to record their sessions.
Sad but true. The log file option only works with the new CTERM protocol.
Another Decnet problem is that SET LOG CONSOLE doesn't work right;
event messages are never typed out in the operator window and if an
event occurs, the EVL process tries forever to start itself and fails
with a non-fatal bugcheck.
I've not heard of it before, but I'd look to see if OPCOM is running, and I'd
also look to see that EVL is installed with privs (SYSPRV, SYSNAM and OPER),
and can write in SYS$MANAGER: and other assorted silliness. Failing that,
try using the LOGGING MONITOR option and let OPCOM do the talking.
Memory: I am setting up large user working sets, in the hope that
one user can use close to all the physical memory in a process.
The vax in question has 9M in it. I give a user about 16000 pages
WSEXTENT. If the process grows to a large size, it indeed sucks up
a lot of this available memory, but it *also* sucks up a lot of the
pagefile, which I claim shouldn't happen if the process working set
is large enough to hold the process's memory.
When you grow working set, VMS also reserves space in the page file (for
dirty pages; clean pages just get sucked back in from the image file or
global section when needed) for a place to put these pages when it pages
them out. If it didn't do that, and the swapper decided that the system
was memory hungary and started trimming people back to WSQUOTA, what would
it do with all of these dirty pages in this 16Kpage working set?
When the pagefile is more than 50% used for any length of time, the
box has a strong tendency to wedge completely.
Critical processes will get stuck in resource wait, waiting for free page
file space (RWPFF). The solution is to have a page file which stays, on
the average, under 50% full. You should hear some squawking from VMS once
the page file gets to be 70% full, and again at 90%, and again above that
(though the last time it'll be a bug check and not a squawk).
Hope this helps.
gkn