🚀 go-pugleaf

During high school I took several mathematics and computer science
classes at the University of Wisconsin, Milwaukee.  These were held in
the Engineering and Math Sciences building.  In this building was a
student-accessible computer lab containing a PDP-8 and several terminals
attached to a VAX-11/780.  The lab was always accessible since someone
had filled the keyhole of one of the building's doors with solder,
making it impossible to lock (it is still that way to this day, or at
least was 6 months ago).

When I started hanging around the lab, I was given an account on the
PDP-8; but that machine was very old and died the final death less than
a month later.  I was then given a non-priveleged account on the VAX.
The VAX had a dial-out modem which I sometimes used to call one of the
2 or 3 BBSes (RCP/M or CBBS) that existed at the time in Milwaukee.
I forget its name, but I used a communications program written by one of
the VAX lab hackers.

The program started by asking for a device name; normally one responded
"TTA2:" (or whatever the modem was on).  Once, for the heck of it, I
told it "DMA1:" -- the user-storage disk drive.  Then I told it to
change the drive's baud rate.  Under VMS, this is accomplished by a QIO
call that is somewhat analogous to UNIX ioctl call.  The comm program
blindly sent the disk driver the bit pattern which would tell a terminal
driver to change baud rates.  I never did check what that pattern meant
to the disk driver, but its effect was immediate and final: that drive
became inaccessible.  At the time I thought it was even worse -- I
thought I'd destroyed the drive.

The VAX-11/780 has a console processor and watchdog, I believe an
LSI-11/03, which will reboot the machine after a crash.  But this wasn't
a crash -- the system was still running, it was just impossible to do
anything useful with it.  What I needed was a way to crash the machine,
but my account didn't have any of the necessary privileges.  Nobody else
in the lab at that moment could do it either.  It was late at night; it
began to look like we'd just have to leave the machine in this
half-crashed state and let the system manager deal with it in the
morning.

Finally someone came in who had system manager priveleges; but for some
reason he was unable to crash the machine either.  I remember he wrote a
simple crash program and couldn't get it to work -- something on the
order of 'change mode to kernel; HALT'.

At this point someone arrived who had a key to the machine room down the
hall.  We burst in there only to find that the front panel keyswitch was
set to disable the console, and nobody had a front panel key.  

After some discussion and hair-tearing, we settled on a last-resort
solution: we unplugged the machine and plugged it back in.  And what do
you know, it booted up just fine and everything was back to normal.

The communications program was soon modified to accept only >terminal<
device names.

So remember, never change your disk drive's baud rate.  ;-}

Bela Lubkin    * *    //  fi...@gorn.santa-cruz.ca.us  CI$: 73047,1112 (slow)
     @       * *     //  be...@sco.com  ..ucbvax!ucscc!{gorn!filbo,sco!belal}
R Pentomino    *   \X/  Filbo @ Pyrzqxgl +408-476-4633 and XBBS +408-476-4945