From: James E P Saari (jamess@misg.csd.harris.com) Newsgroups: alt.folklore.computers Subject: Old iron At my university (nameless), the computing center had four customers: The University Administration; The Hospital; The Agricultural Extension; and The State. You will notice that "the students" are not included. Well, we got to use the computing center, too, but it was because they were a hell of a bunch of guys. (And The State had mandated that there would be a _single_ computing center on campus and that there would be no competing computing resources, including mini's and pc's). Now, the computing center programmers were clever. This was an Amdahl 470 computer running MVS. TSO was still a squallering infant, which 5 terminal sessions would strangle a _large_ 370 class machine. And the normal RJE system and batch executive were burdened by the absurd nature of the environment. So, they developed a simplified editor/file manager/job submission system that allowed interactive use of the machine. For the limited number of expensive terminals they could afford, they now could allow support of a more modern environment. Also, they invented job submission Class S (student or small, your choice: the name was chosen to calm and cajole The System Administrators) , which "chunked" a number of small batch jobs, like the programming class projects, into a large contigruous job, and allowed the dinosaur to graze on the food it had been tuned to handle: big meals. Class S required limited job size and execution times. (Boy it was a pisser when your job was _just_ a little to large and Class S kicked it out. For most, this was a blessing, and infinite loops did not eat all your account pseudo-dollars, for which you had to beg the teaching assistant for more of.) However, during the day (8:00-5:00), The Customers got absolute priority on the system. So, those of us with the Class S jobs came in a 7:00 and got a little done, then went to class, because surely that job submitted at 8:01 would not be out until 13:00 or 17:00, depending upon the dinosaur's appetite. Now comes the Ivan Boskey part of the story. Being familiar with the above scenario, and being an RJE site operator in the engineering school, I came to care for my charges. These poor innocents knew nothing about the system, especially the ones who did not know how to run The Terminals. These poor retches were relegated to THE CARDPUNCHS. Syntax errors in Class S, the sort of thing that happens regularly to people using cardpunchs that should have had a FUBAR tag, can be fatal to someone trying to do things at the last minute (read: everyone). This stirred deep emotions in me, and I had to find a way to make life easier for The Students. I knew a grad student who related to me a program that would run, but scrogg the OS after it had completed. There was apparently a bug in the exit logic in the OS, and his project required him to do his own paging (radar simulation, big arrays, you know...). I got the piece of the program that would do the job, and could submit the job using my student account (real money, monthly bills, but only costing about $.10 (american) to run). If a particularly large group was huddled in the printer room waiting for what would likely not happen before the next class, I would submit my job. BOOM, the OS crashes. Now this may seem to be a bad thing for most everybody. No No No. The Customer's jobs ran on large files and big, sequential job streams that had to be run in order. Intermediate files weren't good enough for The System Administrators. "Rerun the Whole Job". Cleaning up the mess took about 90 minutes. But Class S had no file requirements (remember the restrictions?) and the jobs ran just as soon as the OS was IPL'd again, about 15 minutes (fast for an IBM, but these guys had practice). So, 15 minutes later, the printer room was empty of the poor lowly retches, who had figured out their logic errors while waiting, verified the error from the output, and resubmitted the corrected program, and gone to class. Then The Customers had to wait until after 17:00. Good Night! From: Ken Brunell (khbsnsr@jupiter.nmt.edu) Date: Mon, Oct 29, 1990 Subject: Old Games Newsgroups: alt.folklore.computers In article <1990Oct29.131953.9798@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes: >In article <1548@umriscc.isc.umr.edu> Mike Castle writes: > [ Story about radio interference by computers ] > >I have a Star Trek program for my Altair that I have never run but the >instructions include placing a radio near the computer set for a specific >station. It seems that when a Klingon is hit, it does certain routines >that cause the radio to make the sound effects. Anyone have this that >actually tried it? > At our mid-school, we had a TRS-80 Model 1, on which a small group of us spent all our free time. Anyway, as I recall, one of the games on it had that same feature, sounded kind of funky, but neat. Of course we were thrilled with the ~30 character per second, uni-directional, UPPERCASE only lineprinter I :-> From: Esther C. Filderman (ef1c+@andrew.cmu.edu) Date: Tue, Oct 30 1990 Newsgroups: alt.folklore.computers Excerpts from netnews.alt.folklore.computers: 30-Oct-90 Re: Nite shift batch jobs Nik Conwell@bu-it.bu.edu (993) > > I once heard from a friend, that good operators could generally tell > what was happening in the system due to the noise that the dot matrix > printer would make as the console log messages went to it. Yup. In my ~ two years as an Operator here, I [and others] learned to do just that. On the six Tops-20s we had [now (*sob*) gone] things were easiest. They had a beep code. Six beeps was a system crash. 5 was an impending shutdown. [never did hear a 4] 3 was a request [tape or disk mount, usually]. 2 beeps was a device wanting attention [printer offline, job interrupted, etc]. Two beeps a second apart was a front-end hiccup [temporary loss of communication with the KL10 front-end]. Not only that, but tapes dismounting, disks dismounting, batch jobs completing or certain system jobs running had their own distinctive sound on the DecWriter. You could practically run the machines blind. God, I miss them. Some of the other machines weren't quite as simple. There was a 5 machine vax cluster. The sound of someone breaking out of a cluster is noisy as hell!! The sounds of OPCOM on five consoles printing and beeping quickly is a good clue something has gone wrong. And of course, all the Vaxen would give the tell-tale dump print when they crashed -- another easy one to learn to recognize. There were others, but those were the biggies. I once commented to one of the managers that it was like working in a fast food place. Next time you visit one, listen. You'll notice that most of them have a bunch of noise signals. One means drive thru, another means the fryer is done, another means something yet still. It's all the same. With printers, you can practically listen your way through the job. From: vu0350@bingsuns.cc.binghamton.edu (alley cat) Newsgroups: alt.folklore.computers,alt.sys.pdp8 Subject: Re: Looking for computer tales ...i'd be happy to relate two stories from my high school days, where we had a PDP-8/e... You've heard (or read, perhaps in the jargon file) about `walking the drives' of computers? ...well, some call it a myth, but i *did* it, and i have witnesses (Larry Kolodney, where are you?)...in retrospect, it was a foolish thing to do -- i could have done serious physical damage to the system...but i was a kid, and after hearing what the effects would be, i just *had* to try it... ...i didn't know enough assembler (PL-1?) to access the RK05j disk directly, so i programmed a BASIC kludge to sort of simulate what i wanted; i wrote two BASIC programs, one called A.BAT and one called B.BAT, each of which consisted of a single line -- A.BAT contained the line CHAIN B.BAT and B.BAT contained the line (you guessed it!) CHAIN A.BAT (what do you want, alt.hackers material? ...i was a neophyte!)...i then did some manipulation so that a DIR command indicated that these files were fairly far apart from each other, and let her rip... ...what followed was *exciting*...the first thing i noticed was that the disk access light on the front panel, which generally flickered a few times once in a while, was a blur of action...then, as the quickly vibrating read/write arm set up sympathetic vibrations in the cabinet, the whole thing began to shake...gently at first, but then to a far greater degree (almost like an off-balance washing machine)...i'm not sure the cabinet actually moved from its location on the floor, but it was damn near ready... ...and at that moment, Mr. Mezzadri, who was in charge of the computer, walked into the computer room, noticed the computer sounded *strange*, saw the disk access light freaking out, and *ran* for the on/off switch with key in hand...he was incredibly pissed off, knew exactly who was responsible (Larry and i were basically the only people in the whole school, Mezzadri included, who knew how to pull stunts like this), but somehow i got into virtually no trouble... ...well, maybe after that story the next will seem somewhat anticlimactic, but what the hell, it brings back fond memories... ...Larry & i used to have contests of all kinds, mostly `beat each other to the front of the class with the first correct program' type of thing...we devised a contest to see who could come up with more ways to crash the system, but it eventually became a mutual project...here's some of the ways i remember: 1) The easiest: We had a mark-sense card reader; the BASIC command to read cards from it was CDR...if you typed CDR & forgot to turn the card-reader on (or if you purposely turned it off first ;) the system would grind to a halt *instantly* :O 2) You could easily overflow the interrupt stack with CTL-C's...one way was to just lean on the CTL-C button; another was to make a punched paper-tape consisting of a series of CTL-C's & feeding it into the ASR-33... ...hmmm, i don't seem to remember any others off-hand...so how did y'all spend *your* high school days? :) -allen From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: Looking for computer tales Newsgroups: alt.folklore.computers,alt.sys.pdp8 In article <1sck30$rse@bingsuns.cc.binghamton.edu> vu0350@bingsuns.cc.binghamton.edu (alley cat) writes: > >...i'd be happy to relate two stories from my high school days, where >we had a PDP-8/e... Which is programmed in PAL, not PL-1. Rocking machines, including -8's has been done a few times. You can really get an RK05 to shake, and using overlapped seek operations, you can get it *really* shaking if you have multiple drives. I have written a diagnostic for the SCSI disks on the 8/e-8/a which tries all of the possibly rock-seek sequences deliberately to find "resonances" in the system that make it flunk, etc. You can include up to four simultaneous drives in the test (hardware limitation). I once started the test up, and it eventually failed! (It turned out that it overloaded the PC-type switching power supply. Using a bigger supply made it work fine again.) Even these little MFM drives can shake up a mean storm when mounted in the H960 cabinets. Apparently, the cabs are just loose enough to get a real shake going if you hit the correct rate, etc. On a slightly different subject, I was privileged to go to the taping of the demo videotaping of a tentative TV quiz show called The Computer Game. It started with the opening shot of the PDP-8/e front panel, which was identified as "Mini" the mini-computer. The host was (Dandy) Dan Daniels, (somewhat) famous radio/TV personality/disk-jockey. Fake contestants were played by well-known faces, i.e. people who's name you don't know, but you see all the time - TV commercial actors. The 8/e had two RK05's, and the producers wanted it to move somehow in a way that the audience could see. But no effect could be accomplished with the disks that was acceptable. Eventually, they solved the problem a little differently: there were also a pair of TU56 drives on a TD8E on the machine as well. They applied black plastic electrical tape to the front of the reels of the DECtapes, and then on queue, the tape was rocked back and forth a few times in sync with some pre-recorded music. The whole thing did look rather cute, etc. The contestants were to "challenge" the -8 to some kind of word game. The machine couldn't lose; the entire dictionary was available as a file. They were going to "handicap" the -8 somehow if the show was picked up, so that contestants might have a ghost of a chance of winning, etc. The show was never picked up by the network (CBS). I still have the ticket to the show as a memento. cj "Won't apply electrical tape to DECtape reels for food" l From: ben@nj8j.atl.ga.us (Ben Coleman) Newsgroups: alt.folklore.computers Subject: Re: drum memory? Date: Tue, 07 Mar 95 02:18:50 -0500 DCONGDON@news.delphi.com (DCONGDON@DELPHI.COM) writes: > > Not quite....drums did have fixed heads but some disk drives also > had fixed heads (one per track). This was especially true in early > disk drives. The actuated head came later. Yup. The first Burroughs machine I ever got to work with (a B3800) had HPT(Head-Per-Track) disk for the system and program storage(a.k.a. 100-byte media, because the disk was formatted with 100 bytes per sector. The disks normally used for data, which had movable heads, were formatted at 180 bytes per sector, & called 180-byte media. Eventually, as movable-head disks speed up til HPT disk either didn't give that much of a speed improvement or wasn't worth the extra price(I'm not sure which), you'd made a '100-byte' media disk by strapping a 180-byte drive to ignore the last 80 bytes in a sector). Ben -- Ben Coleman NJ8J | "All that is not eternal is Internet: ben@nj8j.atl.ga.us or | eternally out of date." bcoleman@mindspring.com | C. S. Lewis Newsgroups: alt.folklore.computers From: psmith@wellspring.rtp.dg.com (Peter Smith) Subject: Re: drum memory? Date: Wed, 8 Mar 95 20:55:45 GMT In article <3jfn7n$kh1@news.icaen.uiowa.edu> dsiebert@icaen.uiowa.edu (Doug Siebert) writes: >How did they achieve a 96us access drum? I assume it was multiple sets of >heads, because the thought of something that large rotating at > 10,000 rpm >is a scary prospect! Sounds about right. In the early 1970's at Dartmouth we had a pair of Univac "Firehose" drums for swapping on the time-sharing system. They spun at 3600 RPM with three sets of heads per track (ie., every 120 degrees around the circumfrence), giving an average latency of 92.6 usec. As I recall, they were rather finely-tuned machines, and spinning them up from a cold start took a large fraction of an hour, so as to ensure a very gradual approach to operating temperatures and tollerances. -- Peter Smith -- psmith@wellspring.us.dg.com Data General Corp., Westboro, Massachusetts (for whom I do not speak) From: jcmorris@mwunix.mitre.org (Joe Morris) Newsgroups: alt.folklore.computers Subject: Re: drum memory? Date: 11 Mar 1995 13:56:45 GMT "Bill Cornutt" writes: > >I never saw a drum on a 360. There were several drums from IBM for the S/360: 2301/2302/2303 which provided various performance levels (and corresponding prices). Back in those days the enclosure designers still were in "display mode" and built the drum cabinet with glass sides to let the tourists see the guts. At least with a drum there was more to see than in the memory cabinets (anyone remember the LCS boxes?) which had glass panels to let you contemplate the magnetic cores. > IBM did make a "data cell" thing. >It had a cylinder about a foot in diameter and two and a half feet long. > [...] The 2321 Data Cell was a nice idea that was implemented in a way that would embarrass Rube Goldberg. It was designed to provide massive (for the time) DASD storage capacity at the expense of access time. It's far too long ago for me to be sure, but my recollection of the capacity goes: 200 KB per strip 10 strips per subcell 10 subcells per cell 10 cells per 2321 for a total online capacity of 200 MB. That's trivial in today's world, but back when it was designed a typical disk drive (which might occupy 5 square feet of floor space) provided only a few MB of storage. The data cell came to be the Rodney Dangerfield of the IBM mainframe world: it never was given any respect by the user community. Robert Rannie, then of Oak Ridge National Labs, still gives out old data cell strips at SHARE for attendees to wear to show that they support unsupported systems. >A story about the drum memory was that when the government stopped >using them, they would make sure that the drum media was distroyed >if there had had ever been any classified data on it. That's true of *any* recording medium if it cannot be adequately erased. How much erasure is required (and in some cases no amount is sufficient) depends on the security classification of the data; if you can't adequately erase the disk it must be destroyed. (A while back I was managing our computer center here, and from time to time had meetings with the Document Control supervisor. He kept a large sledgehammer in his office for the times when a disk drive had to be destroyed.) Joe Morris / MITRE Newsgroups: alt.folklore.computers From: jitze.couperus@cdc.com (Jitze Couperus) Subject: Re: drum memory? Date: Mon, 13 Mar 1995 22:47:09 GMT In article , J. Chris Hausler wrote: > > The other one was the RCA RACE (Random Access Card ????) which > I came to know cause it was attached to the same machine that the above > CDC disk unit was attached, a Bendix (labeled CDC) G-20. This was the first > machine I learned to program on (in ALGOL...I feel like I speak Latin). I > think the reason it worked was that the cards were made of a much thicker > material than the Data Cell's and thus they didn't tend to crumple (not that > they never did however, but it was not their major mode of failure). I do The RCA RACE engine was also available on the RCA 301 and 3301 machines and their re-badged counterparts ICT 1500 and Bull Gamma 30. This was a dangerous device if the maintenance engineer didn't re-assemble correctly after maintenance - the "cards" were kept in trays from which a single card could be programmatically selected, it was then sent down a raceway on the end of whaich was a deflector mechanism that caused the card to get wrapped around a drum-like assembly. The card would stay wrapped on the spinning drum (to be read and re-written for as long as desired) until the program selected another deflection arm which caused the card to be "peeled" off the drum and sent down a return raceway back to its storage tray. If the engineer neglected to replace one of these deflectors after "cleaning the heads" (remember the smell of toluene and iso-propyl?) and the skins hadn't been put back on (they never were..) then then a selected card would be shot across the machine room at great velocity... > not know the storage size of either the RACE, CRAM or that large CDC disk > unit. (If anyone DOES! I would sure like to find out!!!) I think the disk you are referring to was known as the CDC 6603 built by Bryant Excello (spelling?) and also available on the RCA machines. Actual capacity is difficult to describe, it had 2 "zones" of differing capacities, an "inner" zone where the smaller circumference of the tracks permited less storage space and the "outer" zones where more data could be stored per track. The arms were moved hydraulically and judicious programming (it was alleged - maybe apocryphal) could cause it to dance across the floor like an out of balance washing machine. The disks were about 1 meter in diameter, and there were 12 surfaces for recording (the data stream to the device was 12 bits wide, and each bit went to a different surface - speed through parallelism) and the disks were mounted on a horizontal shaft. Each arm held 4 read/write heads that each could sweep 128 tracks My reference manual for the Chippewa Operating System (Dec '65) tells me : "...The basic unit of storage is a half-track consisting of either the odd or even numbered sectors on a physical track. There are 2048 half tracks in each cabinet, and each half-track contains 64 sectors in the outer zone and 50 sectors in the inner zone. Each sector has a data capacity of 320 12-bit bytes..." If I understand it correctly, we have 2048 * 114 * 320 * 12 = 896,532,480 bits total capacity, or a little over 112 meg by todays reckoning - all this in a unit of about 5 foot high, 8 wide, 4 deep (roughly from memory) -- Jitze Couperus | jitze.couperus@cdc.com Control Data Systems Inc. | Voice (408) 541-4334 1306 Orleans Drive, Sunnyvale, CA 94089-1135 | FAX (408) 541-4206 From: J. Chris Hausler Newsgroups: alt.folklore.computers Subject: Re: drum memory? Date: Wed, 15 Mar 95 20:57:19 -0500 Jitze Couperus writes: > >down a raceway on the end of whaich was a deflector mechanism that >caused the card to get wrapped around a drum-like assembly. The card >would stay wrapped on the spinning drum (to be read and re-written for as long >as desired) until the program selected another deflection arm which caused >the card to be "peeled" off the drum and sent down a return raceway >back to its storage tray. If the engineer neglected to replace one of >these deflectors after "cleaning the heads" (remember the smell of toluene >and iso-propyl?) and the skins hadn't been put back on (they never were..) >then then a selected card would be shot across the machine room at >great velocity... YES!! YES!! In the particular installation I wasa involved with, an RCA 501 acted as an interface between the RACE and the G20. There were two RACE units in the room with the 501. One (I was an undergrad EE working a couple of shifts a week at the schools computer center) had to remember to go over to the 501 and disable access to the RACE when cleaning the heads and the drum. One night one of the other part time operators forgot to do this and while the unit was open and being cleaned the G20 asked for a card. The selected card dented the front of the 501 which was about 5 feet away from the RACE. On the units I worked with you had to open the plexiglass cover over the drum and remove a framework that deflected the card onto the drum. I was told that in an earlier unit the deflector as on the plexiglass door and that all one had to do allow the card to be ejected accidently was to open the door. I still have one of the RACE cards in its original envelope. >each bit went to a different surface - speed through parallelism) >and the disks were mounted on a horizontal shaft. Each arm held 4 >read/write heads that each could sweep 128 tracks Everything you say sounds right except the disks rotated on a vertical shaft. I never saw it move around on the floor but in our case I believe it was securely fastened. Chris