[Info-vax] Y3K for PDP-11 Operating Systems

[Bob Koehler]

In article <696a284f-1e28-499f-bcec-bb21ccf7cbc9 at l14g2000pro.googlegroups.com>, John Wallace <johnwallace4 at yahoo.co.uk> writes:
> 
> I remember one of my 1980s customers whose hardware service was done
> by a 3rd party. Their 2*78x cluster had a problem in that one node
> wouldn't mount one of the shared disks. They'd been waiting for their
> fixit folks to sort this for months, no progress. Then one day the
> other 78x failed, leaving them unable to produce vehicles (cars, and
> an IT company in this picture which is now part of HP, work it out).
> As a favour, DEC Field Circus came in, ran the usual diagnostics, and
> within minutes it emerged that an FPU fault had been preventing the
> disk being mounted on the original dodgy 785. It was a bit of a
> surprise to me to see an FPU involved in mounting a disk, but
> apparently it shouldn't have been a surprise.

   The FPA for the VAX-11/780, and I believe for the 785, was part of
   the data path between RAM and CPU.  When the CPU fetched and
   instruction that was implemented in the FPA, the FPA executed it,
   presented an instruction to store the result, and padded with NOPs
   to maintain instruction alignment.

   When the FPA went bad, all kinds of screw ups could happen.  I was
   quite suprized to find an FPA bug that created incorrect behaviour
   in our applications by dropping bits, but allowed VMS itself to
   run all day long.  We finally found the bug by running the Fortran
   compiler repeatedly to put a load on the CPU.  From time to time
   it would die, and we were able to see that a RET had gone to the
   wrong address, one bit different from the saved PC.

   Pulling the FPA made everything work correctly.  We ran without it
   for a couple of days until the replacement showed up (third party
   maintenance, didn't keep one in stock).