Subject: Old iron
From: James E P Saari ([email-masked])
Newsgroups: alt.folklore.computers

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 ([email-masked])
Date: Mon, Oct 29, 1990
Subject: Old Games
Newsgroups: alt.folklore.computers

In article <[email-masked]> [email-masked] (D'Arcy J.M. Cain) writes:
>In article <[email-masked]> 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 ([email-masked])
Date: Tue, Oct 30 1990
Newsgroups: alt.folklore.computers

Excerpts from netnews.alt.folklore.computers: 30-Oct-90 Re: Nite shift
batch jobs Nik [email-masked] (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: [email-masked] (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: [email-masked] (Charles Lasner)
Subject: Re: Looking for computer tales
Newsgroups: alt.folklore.computers,alt.sys.pdp8

In article <[email-masked]> [email-masked] (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: [email-masked] (Ben Coleman)
Newsgroups: alt.folklore.computers
Subject: Re: drum memory?
Date: Tue, 07 Mar 95 02:18:50 -0500

[email-masked] ([email-masked]) 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: [email-masked] or   |  eternally out of date."
          [email-masked] |                 C. S. Lewis

Newsgroups: alt.folklore.computers
From: [email-masked] (Peter Smith)
Subject: Re: drum memory?
Date: Wed, 8 Mar 95 20:55:45 GMT

In article <[email-masked]> [email-masked] (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 -- [email-masked]
Data General Corp., Westboro, Massachusetts  (for whom I do not speak)

From: [email-masked] (Joe Morris)
Newsgroups: alt.folklore.computers
Subject: Re: drum memory?
Date: 11 Mar 1995 13:56:45 GMT

"Bill Cornutt" <[email-masked]> 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: [email-masked] (Jitze Couperus)
Subject: Re: drum memory?
Date: Mon, 13 Mar 1995 22:47:09 GMT

In article <[email-masked]>, J. Chris Hausler
<[email-masked]> 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                               | [email-masked]
Control Data Systems Inc.                    | Voice (408) 541-4334
1306 Orleans Drive, Sunnyvale, CA 94089-1135 | FAX   (408) 541-4206

From: J. Chris Hausler <[email-masked]>
Newsgroups: alt.folklore.computers
Subject: Re: drum memory?
Date: Wed, 15 Mar 95 20:57:19 -0500

Jitze Couperus <[email-masked]> 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