Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 8/28/84; site lll-crg.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!brooks
From: brooks@lll-crg.ARPA (Eugene D. Brooks III)
Newsgroups: net.arch,net.micro
Subject: Re: Re: This is serious!
Message-ID: <769@lll-crg.ARPA>
Date: Thu, 8-Aug-85 00:16:01 EDT
Article-I.D.: lll-crg.769
Posted: Thu Aug  8 00:16:01 1985
Date-Received: Sun, 11-Aug-85 04:16:50 EDT
References: <2264@amdcad.UUCP> <> <1601@amd.UUCP>
Organization: Lawrence Livermore Labs, CRG group
Lines: 18
Xref: linus net.arch:1459 net.micro:10143

> 
> Another inertia related problem occurred on some of the older timesharing
> systems (SDS 940 comes to mind).  Programs would have a tendency to keep
> running after they were swapped out to the disc.  Sometimes it was really
> tough to figure out what the program counter really should be when they
> were swapped back in!
> 		Tom Crawford

Seriously now, the program counter was swapped out along with the memory
image and the value to set it to was read back in with the memory image.
That the program counter had changed along with the memory image was of
no consequence.  I do remember one poor fellow who had a job swapped out
which had accumilated a lot of time and during this time the disk motor failed.
When the motor was repaired it was wired backwards and the disk ran backwards
This was done on a friday and the machine was left with the backward running
disk over the weekend until the problem was finally corrected the following
monday.  When the disk was finally set straight the poor fellow has lost all
of his accumilated cpu time and the job restarted from nearly the beginning.