uVAX 3900 out to lunch after inactivity - test-drb@ccmp.vtda.org

5 May 2013

...

 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.