5 May
2013
5 May
'13
3:14 a.m.
The long saga of making my recent KA655 acquisition work
continues! It's been mostly smooth sailing since I got
a decent Plextor drive, but there's one persistent problem.
Under VMS 7.3, after a longish period of inactivity (I've
seen it after a few hours, but I've not been able to
narrow it down beyond that), it seems to just kind of go
out to lunch. VMS is still *running*... if I have a
Telnet session running MONITOR, the clock will still update
and the activity meters still move (a little; they show
very little activity, but that's expected since there's not
a lot going on on the machine yet). But if I terminate
MONITOR (it responds interactively to ctrl-C, etc) and try
to run anything else (say, HELP), it stops responding.
Other terminals are totally unresponsive. If I try to
open a Telnet session, TCP connects but no other traffic
happens.
This also happens if I turn TCP/IP off. I'm running with
16 MB RAM, which should be enough for a machine that's not
really running much yet, and if I were having memory issues
I would expect things like existing MONITOR sessions to
have serious problems.
The only other correlation I can think of is that this
seems to happen most when I've just installed a layered
product, so it could have something to do with the CD
still being mounted. On the other hand, I tend to leave
the machine alone and unattended for long periods of time
for product installs, so correlation is necessarily not
very trustworthy here.
I can still issue a break from the terminal and boot again
from the console firmware, so that still seems fine.
If anyone has any idea what might be going on here, I'm
all ears.
Do either of:
$ REPLY /ENABLE
$ SHOW ERROR
show up any problems? You might need:
$ SET TERMINAL /BROADCAST
and/or
$ SET BROADCAST=ALL
with REPLY /ENABLE if you are doing this on the console and something has
disabled broadcasts on the console.
In older versions of VMS,
$ ANALYZE /ERROR
used to be very useful for spotting behind-the-scenes hardware problems and
worked straight out of the box but it was replaced in later versions (on Alpha
at least - I'm not sure about VAX) by
$ DIAGNOSE /TRANSLATE
which required extra software to be installed and possibly licensed first.
I lost track of what happened after that but I think that was replaced
again by something else equally difficult to make use of :-(
Your disk could be going to sleep but it seems unlikely that it would
recover by just halting and rebooting the system.
With VAX/VMS, having lots of physical memory is neither necessary nor
sufficient. More important is how the virtual memory system is configured.
Perhaps you are low on pagefile space or non-paged pool or something like
that?
Use
$ SHOW MEMORY /FILES
to check how much free pagefile space you have.
$ SHOW MEMORY /POOL /FULL
will give a vast number of figures. If "Free space" is low and "Current
size"
is much bigger than "Initial size" and approaching "Maximum size", you
may be
running into problems with non-paged pool.
If there are no hardware problems, an AUTOGEN might well help. For best
results, it should be done after whatever activity that might have used up
resources but it's obviously no good if the machine stops responding in the
middle of the AUTOGEN procedure. Tell AUTOGEN to save feedback and use it
when calculating new system parameters. It will complain that the machine
wasn't up for 24 hours but tell it to do it anyway.
$ @SYS$UPDATE:AUTOGEN HELP
for further details.
Regards,
Peter Coghlan.