Hello everyone:
Thank you all for taking the time to read and respond to my question.
My deep gratitude goes to
Alan <alan_at_nabeth.cxo.dec.com>
Sheila Hollenbaugh <shollen_at_valhalla.cs.wright.edu>
Donald L. Ritchey <dritchey_at_cecc.chi.gov>
Harald Lundberg <hl_at_tekla.fi>
William Flett <will_at_dcs.rhbnc.ac.uk>
for their swift reponse and generous help.
Here is the solution to the problem, as pointed out by Alan
<alan_at_nabeth.cxo.dec.com>:
Reboot the machine, and "monitor" works fine afterwords. I rebuilt the
kernel some time ago, and forgot to reboot due to heavy sys load at that
time. :-(.
An excerption from Alan's reply:
For the 2nd question the running kernel has the match the
namelist in /vmunix. If you booted an alternate kernel
and haven't renamed it then there will be address mismatches.
Many of the programs that used to depend on the kernel list
can use other methods to get the information. Some of Monitor's
information was only available by reading /dev/kmem (though
many data options don't need to read from /dev/kmem).
A few more things you might want to watch for when running "monitor":
1) make sure SGID bit is set and group owner is "mem", unless you only
want root to run it;
2) If "monitor" is accessed via NFS, make sure the remote fs does not
have "nosuid" restriction ("mount" command gives this info).
By the way, the source code for "monitor" is available as
ftp://gatekeeper.dec.com/pub/DEC/monitor.alpha.Z
Best Regards;
Wu Wei
Received on Wed Nov 22 1995 - 18:52:08 NZDT