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.