Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!snorkelwacker.mit.edu!primerd!tiger1!barry From: barry@tiger1.Prime.COM (Barry Wolman) Newsgroups: comp.arch Subject: Re: IBM 7094 II Message-ID: <1990Dec3.134558@tiger1.Prime.COM> Date: 3 Dec 90 18:45:58 GMT References: <9011272349.AA25956@ucbvax.Berkeley.EDU> <1990Nov28.143631.725@athena.cs.uga.edu> Reply-To: barry@tiger1.Prime.COM (Barry Wolman) Organization: Prime Computer, Inc. Lines: 71 Nntp-Posting-Host: tiger1 In article <1990Nov28.143631.725@athena.cs.uga.edu>, is@athena.cs.uga.edu ( Bob Stearns) writes: |> The IBM 7094-II was a 32K word (36 bits/word) processor follow on to the |> family 709-7090-7094. At its best (my memory may be failing here) it was |> capable of something like .2MFLOP. This is an oldy-goldy scientific |> processor built before the "universal" 360/370/390 architecture. It was |> programmed entirely from banks of tapes attached on primitive channels; very |> few 7094's ever had the RAMAC disk drives. All input (cards) and output |> (printing) was done offline using IBM 1401's. FMS (Fortran Monitor System) was a simple OS oriented towards running Fortran and assembly programs in a scientific enviornment. I believe FMS was written by members of SHARE, the IBM User Group. The University of Michigan, where I got my undergraduate degree, had its own executive (called MESS, as I recall) optimized for running student MAD programs as quickly as possible. An interesting problem with which MESS had to deal was protecting the OS in the absence of hardware protection. If you requested the Fortran compiler (Fortran II in those days), what you actually got was a MADTRAN, which translated Fortran II to MAD, followed by a normal MAD compilation. This process was MUCH faster than using the normal IBM Fortran compiler. As I recall, the first "pass" of the IBM compiler did nothing but copy the input program from the source tape to a scratch tape! The "premiere" OS for the 7094 series was the CTSS operating system developed at MIT, where I did my graduate work. CTSS was available as a production system in 1963 and underwent additional development until about 1967 when most work at MIT was aimed at Multics. CTSS required a modified 7094 with two banks of 32K words of memory. The OS resided in bank A and user programs in bank B. Quite a lot of useful work got done in spite of the limited memory. Garden variety FMS jobs could run as background while interactive users ran in foreground. CTSS was quite popular at MIT and was around until sometime in the early-mid 70s. CTSS had an interesting feature that I haven't seen in any recent OS. A user could interrupt a program at any point and issue the command "save file" to create FILE.SAVED. This preserved the entire state of the computation, including file buffers and positions. Most commands were just files that had been saved immediately after loading. The user could return at an arbitrary time in the future and resume the computation where it had been interrupted. In fact, the computation could be resumed multiple times. A useful debugging technique was to save just before a problem occurred and then explore various paths by rerunning the saved image. If files implicitly associated with the saved file weren't deleted, the user could come back MONTHS later and resume exactly where s/he left off, even if there had been an OS upgrade installed. I'd sure like to be able to do that today! Barry -- ------------------------------------------------------------------------ - Barry Wolman | barry@s66.prime.com Principal Technical Consultant | 500 Old Connecticut Path Prime Computer | Framingham, MA 01701 | 508/620-2800, ext. 1100 ------------------------------------------------------------------------ - Brought to you by Super Global Mega Corp .com