[comp.os.vms] 8xxx system problems

MANAGER@SMITH.BITNET (Mary Malmros) (07/09/87)

Paul Clayton listed a number of problems that he's experienced with his
8500 since Jan 1.  We got an 8500 shortly before that.  I haven't run up
against any of the problems that he mentioned EXCEPT the crashes that are
associated with doing things to/with the console.  Specifically, I have crashed
my system while doing the following three things:

   1.  Doing CONNECT CONSOLE -- system crashed about 5-10 minutes following
       the command.

   2.  Scanning console log -- system crashed sometime within 15 minutes of
       when I started looking at the log.

   3.  Using the console as a terminal to do TYPE and EDT -- console got hung
       up totally when it received several quick XOFF/XON combinations while
       typing a file.  Similar behavior in EDT when receiving several PAGE
       commands (or other commands requiring a screen redraw) in rapid
       succession.  I did this about five times in two days last December,
       right after we had got it out of the box, and the console was the
       only thing that could talk to the CPU, so I really don't know if
       it crashed the system, hung the system, or just confused the console
       such that it would eventually have crashed.


I would really like to hear from other people with bothersome consoles
because I don't know a)what it is or b)what comprehensive steps I can
take to avoid it, short of never touching the console at all. Someone told me
once that it had something to do with the very small bus connecting the console
to the CPU.  Because the bus is small, it can't handle too much stuff going in
both directions, and it gets confused and the system crashes.  Aside from the
lack of detail, I don't like that explanation because at least in case 2, stuff
should only be going in one direction (CPU to console).  Maybe it's got
something to do with acknowledgements--CPU is trying to send stuff to console,
console is busy doing something else and can't accept new stuff or acknowledge
that it got it.  Anyway...I'm almost inclined to think that the problem runs a
little deeper than the operating system and that 4.6 won't fix it.

Warning for all others with 8500/8530 systems:  STABACKIT does a CONNECT
CONSOLE.  I found this out when I had to rebuild my standalone kit following
a microcode upgrade (8500 to 8530).  I called DEC and the answer I got was that
you can't get there from here, and that I would have to build a standalone kit
on something else.  I built the kit on the system disk, so it's no big deal,
but I don't think DEC warns you about this explicitly (just "don't CONNECT
CONSOLE).  I really don't get it because I did do STABACKIT once before and I
got away with it...maybe I just got lucky :)

DHASKIN@CLARKU.BITNET (Denis W. Haskin, Manager, Technical Services) (07/16/87)

> Date:         Thu, 9 Jul 87 14:38 EDT
> From:         Mary Malmros <MANAGER%SMITH.BITNET@WISCVM.WISC.EDU>
> Subject:      8xxx system problems
>
> Paul Clayton listed a number of problems that he's experienced with his
> 8500 since Jan 1.  We got an 8500 shortly before that.  I haven't run up
> against any of the problems that he mentioned EXCEPT the crashes that are
> associated with doing things to/with the console.  Specifically, I have crashe
d
> my system while doing the following three things:

We've had an 8500 since August '86 (it was apparently one of the first
installed in the northeast) and upgraded it to an 8530 (thanks DEC) about
2 months ago.  Excluding the first 3 weeks after installation, problems
have been minimal; most console problems are more annoying than anything.

>   1.  Doing CONNECT CONSOLE -- system crashed about 5-10 minutes following
>       the command.

Yup.

>   2.  Scanning console log -- system crashed sometime within 15 minutes of
>       when I started looking at the log.

Has never happened to us.  I plan on SPRing the SHOW LOGFILE command (if
I ever find the time):
        - some kind of string search would be *great*,
        - they should suppress bells (^G) because most messages on the
          operators' console are accompanied by them and it can drive one
          nuts, and
        - they should supress escape sequences because if you do, say, a
          SHOW CLUSTER command while VMS thinks the console is a DEC_CRT
          terminal, the "line-drawing on" and "line-drawing off" escape codes
          are in reverse order (if you're scanning the log file backwards,
          which is probably 90% of the time) which means one is left in
          line-drawing mode and everything lowercase before that
          point in the log file is pretty much unreadable.

>   3.  Using the console as a terminal to do TYPE and EDT -- console got hung
>       up totally when it received several quick XOFF/XON combinations while
>       typing a file [...]

I assume you mean VMS TYPE and EDT after you've done a >>>SET TER PRO.  Local
operations are fine, but *most* operations using the Pro as a VAX terminal are
quite poor.  I avoid doing anything screen-based on it, as it really garbages
up the log file, and I have seen the XON/XOFF problem -- particularly manifests
itself if you press the 'Hold Screen' or ^S key; everything after that is
fairly useless.

> I would really like to hear from other people with bothersome consoles
> because I don't know a)what it is or b)what comprehensive steps I can
> take to avoid it, short of never touching the console at all. Someone told me
> once that it had something to do with the very small bus connecting the
> console to the CPU [...]

Sounds plausible.  We just avoid using the Pro for anything but real operator
console-type stuff and local operations (that is, manipulating the Pro's
disk).  I don't think there are any 'comprehensive steps' you can take,
besides mailing weekly SPRs to DEC (that works pretty well as a placebo
-- for you, not DEC).

We have had intermittent problems of late where the 8530 will not reboot;
it hangs just after VMB.EXE is loaded, but never displays the first VAX/VMS
banner (just before it introduces itself to the rest of the cluster).  Our
solution has so far been to power down *completely*, which seems to do the
trick ;-) .

Ciao -

% Denis W. Haskin                             Manager, Technical Services %
% ----------------------------------------------------------------------- %
% DHASKIN@CLARKU.BITNET   Office of Information Systems     (617)793-7193 %
% Clark University               950 Main Street      Worcester MA  01610 %
%                                                                         %
%                       "Revenge is best served cold."                    %
%                                -- Anonymous                             %