Printers

10 things I don't miss about Big Iron

Strolling down Memory Lane, you may hit the occasional pothole. Jaime Henriquez returns to his reflections on the age of Big Iron with a look at some things he's glad he left behind.

In 10 things I miss about Big Iron, I reminisced about working in operations at Montgomery Ward's computer center in Chicago in the early 1970s. But it wasn't all fun. Here are 10 things about Big Iron I really don't miss.

1: "Welcome to Siberia"

I don't miss the pervasive noise and cold of all those machines and all that air conditioning. Leaving the floor for a break was like leaving a movie theater -- everything seemed surprisingly warm and strangely quiet. It wasn't unusual to find yourself shouting at people when you first came out.

2: The occasional short Siberian summer

Once in a while, we were forcibly reminded why it was so cold on the floor. One Chicago winter day our AC failed and the temperature rapidly climbed to the point that we had to open the windows. Soon, little snowdrifts were accumulating, threatening to melt and drip down onto the under-floor cabling. The windows stayed open. We were less concerned about melting snow than melting components.

3: Handcrafted application programs

In the age of Big Iron, very few programs were "off the shelf." Your applications were written by in-house programmers specifically for the organization -- handy for customization, a problem for troubleshooting. When errors occurred, you couldn't check the manual or try reinstalling; you had to call the programmer responsible for that program and wait for him or her to deal with it. Perhaps if we had paid more attention to their incessant pleas for testing time....

4: The 5:00 PM telecomm rush

Before networks and cheap same-day delivery service, rapid data transfer was a matter of telecommunication, accomplished over phone lines. Ma Bell's rate structure made it prohibitively expensive to do this during business hours, so at 5:00 PM there was a mad rush to phone Albany, Kansas City, etc., and get the modems running so daily production wasn't delayed. Speed and accuracy were critical, but most of your time was spent waiting for transmissions to finish or for the people at the other end to be ready. It was a bad combination -- high-pressure and stupefyingly boring.

5: Head crashes

Peripherals like disk drives were far more vulnerable to dust and dirt than contemporary storage is. A wayward speck could get into the 85 micron space between the rapidly moving read/write heads and the rapidly spinning disk and damage either of them (usually both). This might or might not immediately generate an error, but eventually a program using the disk would fail -- by which time the disk pack had usually been moved.

Herein lay the real problem: A damaged disk pack could crash other drives, and crashed drives could damage more disk packs. Since disk packs were frequently swapped between drives (and systems), head crashes tended to propagate and get out of hand fast. It was an exercise in epidemiology: Recognize the problem, then track and quarantine the affected packs and drives before it spread. Useful practice, as it turned out, for the computer virus outbreaks of later decades.

6: The 1403 printer

Probably the single most memorable device of the period, the 1403 line printer churned out 23 pages a minute -- so fast the output bin had to be motor-driven just to cope. Our spool system (to which all print jobs were forwarded) had half a dozen of these monsters, whose care and feeding required a degree of personal attention, expertise, and muscle unlike anything else on the floor. They had an attitude, too. When out of paper (or worse), printing would stop automatically and the cover slowly open like the mouth of some great dinosaur, the whine of the spinning print chain suddenly louder. You could almost hear it saying, "Feed me!"

7: Six-part form

In the years B.C. (Before Copiers), the only way to produce multiple copies at one time was to use multipart form, a sandwich of alternating sheets of paper and carbon paper. It came in a neatly folded stack, which unfolded on the way into the printer and (theoretically) refolded as it came out. This worked fine for single-sheet continuous form and fairly well for three-part, but six-part was another matter. Eleven layers thick, it tended to curl rather than fold at the page breaks. Once this happened, all hope of automatic folding into a stack vanished, and the printout just piled up in a mass of curves and loops that ultimately meant refolding the whole printout by hand. Once folded (or stuffed into a box), it went off to bursters and decollators to be turned into single copies. Organizational status was indicated by who got the top copy and who got the barely readable bottom copies.

8: The 2540 card read punch

The 2540 was a two-faced device. The card reader could smoothly read in old, dog-eared JCL decks without a problem and make satisfying noises in the process. The card punch, on the other hand, sounded like it was grinding granite, had to be loaded with fresh new cards, sharp as razors, and when you opened it up to fish out a jammed card, punched-out chips inevitably got everywhere. It was also a common villain in those cautionary (possibly apocryphal) "Why to wear a clip-on tie" stories.

9: Paper cuts and card cuts

After handling stacks of fanfold paper and pulling bunches of data cards out of boxes, it was not uncommon to head home with multiple wounds. Multipart form could produce parallel cuts that looked like you'd been boxing with Freddy Krueger.

10: IBM's hegemony

You couldn't go anywhere else for information or help, which made it possible for them to use runaround tactics to great effect. When you wanted information, every $8.00 manual (that would be $47.00 now) directed you to a different manual, glowing with the aura that it really did have the answer. As for help, when IBM's hardware or software balked, their response often boiled down to "It didn't really do that," then "It did do it, but it was supposed to," and finally, "It did it, and it's not supposed to, but it's better this way."

Additional resources

Other memories... good or bad?

Were you part of the Big Iron era? Are there things you miss about it or were you happy to leave those days behind?

101 comments
lelandhamilton
lelandhamilton

In my early mainframe days (360) I would frequently work at least part of my shift at night, when the mainframe floor was accessible to cooperative users to run jobs directly into the card reader, get printouts, hang tapes, i.e. instant turnaround. (I was single at the time so just had to adjust my waking hours to be awake for dates and meetings. Some weeks slept only six times per week.) . During the day and early evening hours the floor was closed and you had to place your decks in an input tray and wait several hours or more for printouts and deck returns that were stored behind the counter. (Job accounting records showed that I had run over a hundred jobs some nights.) -- Story 1 uncatalogued all files in system I used generation data sets to save intermediate and final data from a complex multistep job to allow restart at an intermediate step or reuse a random access file. Once I was through with these datasets I would run a job that used a pattern search (written in FORTRAN) for datasets that were no longer needed that would create utility command files to uncatalog them, i.e. remove them from the "catalog" a kind of system index, and then delete the datasets. One day I made a mistake in the pattern that matched all files on the system, and promptly uncatalogued everything. (Thank goodness the delete step failed before deleting anything.) Woops! I thought about it for a few minutes before I fessed up to the operators. At least it was 2 or 3 am and not much was happening, so they mounted up the backup made a few hours earlier (thank God) and I ran a pattern that would recreate the catalog to that point. (Thank goods for a card reader program GORDRGO or something like that that would keep the PROCLIB open and allow more jobs to be placed in the card reader without having to start a reader procedure.) Reviewed the search results and ran it. Additional review showed that the only uncatalogued data sets remaining were ones that I had generated after the backup and a few orphaned temporary data sets from days gone bye that were probably the result of system crashes. Told the day crew (that included several computer geniuses) what I did. The only problem turned up several weeks later after a SYSGEN that altered the site assigned generic device names, such as 9TRACK (tape drive) that I had used for several devices. Apparently they were indicated by a SYSGEN generated number that could vary if generic devices were added or rearranged. --- Story 2: blank card caused job failure A feature of the above mentioned procedure was an early procedure step that used IEBGENER to copy data, typically from a card deck to a temporary intermediate file. The procedure had many steps that included liberal use of condition codes, IEFBR14 to handle setting some condition codes, and generation datasets. Specifying a generation number for one of the intermediate datasets would cause the JCL to skip the previous processing, essentially resuming with the step that used the generation dataset for input. The procedure took advantage of the site ignoring the step account fields and very carefully crafted defaults for the generation dataset parameters to accomplish this. The JCL procedure read something like //SOMENAME PROC all kinds of procedure parameters and defaults //INPUTCPY EXEC PGM=IEBGENER,COND= //SYSUT1 DD DDNAME=SYSIN //SYSUT2 DD more mumble jumble omitted here to create a temporary dataset //SYSIN DD DUMMY //SYSIN DD DUMMY // much more JCL for future steps If the user just included their card deck without a //SYSIN DD *or //SYSUT1 DD *, the system would generate a //SYSIN DD *. IEBGENER expected a //SYSUT1 for input and a //SYSIN for control. The //SYSUT1 DD DDNAME=SYSIN took care of the user that would omit the SYSUT1 DD * card, telling the system to look for the next SYSIN data set and use it for SYSUT1. The 2nd SYSIN DD DUMMY would satisfy IEBGENERS need for SYSIN data, and this DUMMY SYSIN would case IBGENER to run a simple copy from SYSUT1 to SYSUT2. One day a user inserted a card deck that executed the procedure, some input cards, a /* or JCL statement that indicated end of input deck, and a blank card. The system added a //SYSIN DD * in front of the input cards and again in front of the blank card, causing the blank card to be read as a control statement. IEBGENER complained about an invalid control statement after printing the control input (a blank line). It took multiple hours for the user assistants and several system programmers to discover the blank card. At one point there were three experts looking at the printout. I think that they got sidetracked with the complex conditional processing built into the JCL procedure. I also believe that the system default message level did not show procedure expansion, so they had to print the procedure to study it along with the job log. The next day my SYSUT1 DD DDNAME=SYSIN and dual SYSIN DD DUMMY JCL was copied in to the various JCL system procedure library procedures that did simple copy operations with IEBGENER and other utilities, such as print, punch, etc, because so many users were used to programs that used SYSIN for card input and had made many mistakes with using SYSIN instead of SYSUT1. Later comment, Lee sure knows how to use JCL as a language. My reply: JCL stands for Job Control LANGUAGE. ---- Question of the day What does IEFBR14 stand for? Answer: IEF indicated a kind of utility. The assembly language in this utility was BR 14 Which any old 360 assembly language salt knows as go to (branch) the address value in register 14, the return address. IEFBR14 returned to the OS without doing anything. Sometimes this would be useful for allocating data sets (that was done before executing the program) and deleting data sets (done after exiting the program). I used it in the above procedure about five or six times to provide condition codes for later steps and some dataset allocation. Can you guess what IEFBR15 would do? On entry to a routine Register 15 contained the address of the routine. IEFBR15 contained a BR 15, essentially a go to here which would loop at the first statement. (The routine actually existed. I think of this as one of many IBM jokes, or was it just a simple diagnostic scope loop.)

Systems Guy
Systems Guy

with reference to item #1. And server rooms don't need AC anymore? While I realize some of this is tongue-in-check comments get some of the facts straight.

grayanalyst2
grayanalyst2

Learning to touchtype on the keypunch Learning BAL from the S/360 Principles of Operations manual (the only IBM manual that didn't assume you had already mastered all the other manuals) Arriving home wearing rubber bands and tape rings on my wrists SOC7s and core dumps (it was easier to solve a problem when you could actually see what happened - except for the program that would get confused and start executing data and end with the PSW pointing somewhere in the data buffer) The time I dumped a coke on a tray of cards - my boss grabbed the tray and ran it through the card reader to tape - better to trash the reader than repunch the cards Hours spent trying to debug a program that was new to me - another programmer wandering by noticed that the input tapes were from 2 different runs of the previous program Still have my IBM Green Card (and the replacement manila-colored card) - it had everything I needed to know 45 years ago learned Basic in college on a hookup to Dartmouth - called myself a programmer and got a summer job programming in Fortran for the Navy (loved being the cool college chick hanging out with all those geeky engineers) Thanks everyone for the memories!

terryameyer
terryameyer

- Being called in on the weekend because a database reorg failed. Discovering that of the 17 big round 9-track tapes, two were missing, one was from another job entirely, several were out of order, and finally, the last one halfway across the room. And I was someone that the operators actually somewhat liked. - Being called at 1:30am, driving to work through heavy rain, spending an hour juggling disk space because we were at the end of a budget cycle, then arriving home to find a message that another job had failed due to insufficient space. + Having a large query return slightly before you take your finger off the button. + Coming in at 3:30am to perform maintenance, then going to eat pancakes at 6:00am before starting the regular work day. + Hearing a story about the operators watching scary movies on Halloween night. At some point, the lead operator left to go to the restroom. Shortly after he returned, at a particularly tense point in the movie, a hand reaches out from the raised floor...and it grabs his ankle. They said he screamed loud enough to trip the tilt switches in the systems.

JohnnyStompanato
JohnnyStompanato

;o) I just remembered another incident. I was working at a large insurance co. in Newark, NJ. In 1968 they had 11 IBM mainframes, from 1401 to 360/165, so had a huge contract with IBM. One day my co-worker friend Bob decided to pull a trick on another co-worker Don. He swapped 2 plastic lenses on a 1403 printer so the ???READY??? condition bulb lit up with a red ???I/O ERROR???. The printer printed OK but appeared to have a constant ???I/O ERROR???. After Bob & I went home for the day, Ed called a CE over to check out the problem. When we returned the following morning we learned that the problem had 5 CEs scratching their heads with racks of those huge blue hardware books, oscilloscopes, and were Able, Baker & Charlieing & for over 3 hours before one of them looked at a nearby identical 1403 & noticed how the lights were normally setup. It was especially serious because the company had been having lack of service issues with IBM & there was a pending lawsuit. Needless to say, the sh*t hit the fan, so Bob confessed. Somehow he was not fired after explaining himself, but he did get all the crap operator assignments for a few months.

2uWrangler
2uWrangler

For those of you who aren't aware, the terms "Big Iron" and "Mainframe" are now misnomers, IBM z/Series machines are no bigger than a large refrigerator, and are air cooled, some even run off of 120vac. I've worked at a number of shops where the power consumption of those racks upon racks of "blade" servers outstripped a z/Series machine by as much as 300%!! AND took up a LOT more space. Talk about Mainframe... What do you think a bunch of blade servers plugged into a series of back-planes all powered from a "rack" is ... a Mainframe.. you mid-range and x86 people have been hoodwinked and bamboozled

onthego
onthego

Miss -- reboot meant MVS was being upgraded, not an application software problem resolution procedure. Enjoyed -- blow-tourching the plumbing on a 370-3081 before having it hauled out of the building for scrap;-) I was surprised it had never sprung a leak for the amount of pipe carrying water through the data center and inside the beast.

JohnnyStompanato
JohnnyStompanato

I was a computer operator in 1970 working the 3rd shift on a 370/135 . One weekend I was running a special year-end payroll at 3AM on a Sunday. One critical job ABENDED and I had to call the programmer. It took him about 5 min. after waking up to become comprehendible. I explained the error & he tried for 30 min. to get me to fix the problem over the phone. I finally told him he better come in. He had a 40 min. drive from home through the ice & snow & arrived in his pajamas & slippers. He quickly perused his COBOL source printout, punched a card fix, recompiled the program, & we re-ran it to NEOJ...all in about 5 min. He drove home OK but this ruined his entire Sunday because when he got home he couldn't get back to sleep worrying about the rest of the payroll run. This incident finally convinced me NOT to become a programmer.

NthDegree
NthDegree

Here are all the things I miss: 1. Sub-sectond response time. 2. An OS impervious to viruses, trojans and worms. 3. Custom software that works the way the business does and not the way some package says to. 4. 24/7/365 uptime. 5. A bigger paycheck. 6. Office staff using terminals instead of PC's elimates shopping online, going to hotbabes.com and other constructive sites. 7. High speed printers that could print a thousand ivoices a minute. 8. Only one operating system to maintain instead of hundreds. And this is just off the top of my head. By the way you can now buy a mainframe that you can put in a corner and plug it into a normal socket and have the computing capacity of a thousand servers for about $250,000. It requires only normal air conditioning and no raised floors.

premiertechnologist
premiertechnologist

The IBM Mainframe is still around... there's still one running in Pierce County. Of course, it is the only one in the whole county. Truthfully, I don't like the hegemony of Microsoft much better in some ways, but I love their developer's products -- if you can afford them!

Jackenator
Jackenator

Could normally recover from an SB-37, but not usually so with the dreaded S0C7. Holy crap! The job blew up with a friggin' S0C7!? Seriously?? Now I get to call that REALLY NICE "gentleman" that can fix it at 3 o'clock in the morning. Hmmmmmm....On second thought, maybe just one more restart on this previous job step...Ah heck! Into the belly of the beast once more! Hello? Mr. Programmer? Sorry to have to call you at this hour, but....

donstrayer
donstrayer

When I started working with mini computers it was so liberating to dispense with JCL. No need to get help from a systems programmer. And since the system command language (SCI with Texas Instruments, and DCL with DEC) included logic, flow control, operators, I-O commands, etc. it was possible to write entire simple applications using nothing else. I never looked back.

thompsgd
thompsgd

* The banks & banks of flashing lights on the Air Force SAGE computer. * Boxing COBOL source decks to be delivered by Greyhound bus to the IBM data center to be compiled, linked, & tested on a S/360 & the output returned the same way. * Throwing up the lid on the line printer to read the listing as it was being printed & conking the operator on the head, who was crouching behind the printer stacking the paper. * Hiding your office mate's source deck & replacing it on the floor with a thoroughly mingled pile of salvage cards. * FFF hard wait. * 30-30 Winchester drives. * The operator who tried to clear a 2540 read/punch jam by pulling out the card under the angled read wires the wrong way. * Missing interrupts & popping plugs * Late night calls from the operator * Pulling an "all-weekender" doing a Sysgen * APARS & PTFS * When I discovered that IBM's S/360 Data Management Guide wasn't just for Managers * Sending a disk pack back to the factory to be repaired because I had a bug in an ALC program that wrote to an unrecoverable area that DDR couldn't access. * Conversions * The proverbial "Compiler bugs" that were actually the fault of the programmer & not the compiler * VM under VM * VM & the Diagnose instruction * The Selectric Operator's console * Microcode * Bus & tag cables under raised floors

gpopkey
gpopkey

Card sorter devices (and I can't remember the device numbers) a la $64000.00 TV show - would occasionally chew up a card and cause a jam-up that took hours to unjam. Those were the days

seanferd
seanferd

Do not fold, bend, staple, spindle, or mutilate.

pbninc
pbninc

Remember the old drum printers? We had an early CDC (remember Control Data Corporation?) drum. The paper dust and the lint and crud from the inked ribbon all mixed to form a goo that would fill in the closed spaces in the letters on characters like "O" and "B" (there were no lower case characters on our drum! It was ALL CAPS, baby!) So, every now and then, an operator had to clean the drum. We used alcohol and a toothbrush. And lots of shop towels. And a drop cloth on the floor. And rubber gloves. And coveralls. And prodigious swearing. Lots and lots of swearing.

allend14
allend14

We used to call them quarter-men, because when you rang IBM with a fault or a problem, they sent four of them - the software guy, the hardware guy, the account manager and of course the ever-hopeful salesman. The first three looked worried, concerned about the trouble you were having, but the salesman couldn't stop smiling through dreams of new upgrades and selling Field Replaceable Units.

texznet
texznet

Early on my state agency didn't have its own mainframe so we had to van over the trays to a larger agency every night. One night the van took a corner too fast and all the trays dumped on the floor. Granted the cards were numbered, color coded, and angle stripped on the top, but it takes a longgggg time to put the decks back together properly. On threat of great bodily harm Operations made sure the trays were strapped down good after that. Lots of changes from 1971 to 1997 when I finally retired! together properly.

sboverie
sboverie

It was fun in the old days, the pay for being a customer engineer was not that great. We were component level troubleshooters with knowledge of how to key in a program into a subcomputer system. What I miss the most from those days was actual training on the equipment you work on, training paid by the employer and it was not for certification only. The materials for self training do not come close to what we got in instructor led classes with practical experience chasing bugs. The Burroughs training center in PA was like living in a hotel and eating at a 5 star restaurant.

atrue
atrue

As the console operator, being the one everyone thought knew what those lights meant. Ah, the power. Inputing the IPL sequence manually into the registers and successfully getting the machine up - wow was I smart! Remember the distinctive clatter of the solenoids as the machine powered up? You could tell if you had a problem just by the sound. Those blinking lights always made me feel like we were really accomplishing something. The IBM 360/370 lights were impressive but then I saw a Burroughs in operation and was humbled. And that darn red emergency pull knob coming out of the upper part of the machine! How many hours of temptation I endured sitting the console looking at that thing wondering what would happen if I pulled it just once.

TAPhilo
TAPhilo

Ah, the 6 part finance reports to print and then decollate every month. Quarterly, only 32 boxes - plus al the other 2 and 4 part printout jobs. Some weekends at the end there were over 60 boxes of paper stacked around the whole reception area for people to pick up (in trucks!). Course on those rare weekends when a person called in sick I had to run the 370/135 (3 partitions), do the microfiche, do the dual 1403s, do the decollating, and run the RJE for the remote offices so their prints got to them do the tape library work. You never were just sitting around watching the screen!

MrsGeezer
MrsGeezer

We had callouses on our cuticles from shoving our hands into trays of cards, and we had to add and subtract in hex to manually wire collator boards. I was the only woman in a team of men, and the only non-smoker. We had power then. Heavy sigh.

clayburne.reid
clayburne.reid

Working as a contractor in an IBM MF shop where the application was stored in object format on punch cards. Only oone person knew how to modify the code because the "SOURCE" was not available. He would replicate the cards and insert "JUMP" or "Branch and link register" statements in the object deck.

rbrown999
rbrown999

You forgot to mention carridge control tapes! When one of those broke a whole box would feed in seconds... then you'd don what was almost chemical protection gear to keep the ink and stuff of your uniform (I was an operator in the Army). Then there was degauzing tapes, or, worse having the Beginning of Tape marker come off on a critical data tape... Making microfiche was only good if you liked sniffing obnoxious chemicals... getting rid of them was worse.

oldbaritone
oldbaritone

My first experience in High School was with APL on a 2741 Terminal (galloping golf ball) and a Bell 103 Dataphone, in a 6x6 foot terminal room with one window. The tilt/rotate bands used to break frequently, and we finally managed to convince the IBM tech to leave us a couple spares and teach us how to replace them, so we could keep the terminal up. I still remember the number - xxx-6809 - ring - beep - push the DATA button! 300 baud! wow...

NickNielsen
NickNielsen

In my experience, any time a large query returned that fast, the job had ABENDed.

Henriquez
Henriquez

When I realized how easily you could do that, I was sorely tempted. Probably a good thing I didn't. Great story!

NthDegree
NthDegree

You hit the nail on the head. Adding your list to my missed things.

bobc4012
bobc4012

@NthDegree Those OSes (TOS/DOS/MFT/MVT -> MVS) have evolved (and been renamed) over time and still run the "Z" series H/W. The best system IBM "never marketed" was their CP/CMS (renamed VM/CMS and now z/VM). I have never heard of any of them being hacked or otherwise. VM was widely used internally by all IBM facilities but didn't bring the H/W drag that the MVS (z/OS) did. 

donallsop
donallsop

In college in the mid/late 70's we ran all the CS/Engineering homework and projects on a 360. We were given a JCL script that directed the output of our program to the big nasty printer, output from which was delivered once per hour to the pickup window. By restricting us to the one-hour cycle, they were trying to teach us to debug the code thoroughly before running it. Well, I figured out a way to direct the output to a file on the disk instead of to the printer, and of course passed it all around to my classmates. The professor and his minions must have noticed the massive increase in jobs being run, because a day or two later, they searched everyone's files and "arrested" all those with a copy of my JCL file. Fortunately, I'd deleted mine by then, and no one ratted me out. Good times!

CharlieSpencer
CharlieSpencer

titles "Programming with DCL". From DEC press, I recall it had a lime green cover and was just full of fun stuff. I miss DCL more than I can say.

Systems Guy
Systems Guy

yeah, always loved the programmers thinking there was a compiler bug. I used to work at a bank DP center and one programmer constantly accused the COBOL compiler of having bugs. I told the person one time that the COBOL compiler has been around a long time and the chances of you finding a bug with it were indeed slim. That usually silenced the person for a while. The only bug, if you want to call it that, I knew of with the COBOL compiler was with the line numbers. When the line number got to 32k, it started back over at 1 (one). This same program was written and maintained by the programmer who said the compiler had bugs.

CharlieSpencer
CharlieSpencer

"Hiding your office mate's source deck & replacing it on the floor with a thoroughly mingled pile of salvage cards." Man, if someone doesn't think that's funny, he needs to turn in his geek card. You are my hero for the day.

DesD
DesD

A new cleaner is vacuum cleaning behind the 1403 one evening when it runs out of paper. She takes one look at the cover rising up towards her accompanied by an increasingly loud roar, and bolts. A winter morning, and there's a funny buzzing noise coming from the 2821 control unit in the corner. Turned out to be a kitten which had gotten into the subfloor through an outside vent, come up via the cable cutout, and was sprawled along the top of the logic gate enjoying the warm breeze and purring loudly. "m * *" meaning "help! where am I?" while running VM under VM. And in the CICS equivalent of the FFF error routine - it gets to the bottom of the possible error codes, still can't find a match, so it forces a crash. The comment said: "There's no reason for this, it's just our policy!" After our last mainframe went, two guys spent the week following Christmas pulling old bus and tag cables out from under the floor. They filled 4 of the half ton bins used by orchardists, and got a tidy return on it from a scrap metal dealer.

Henriquez
Henriquez

Staple? I don't remember staple in there, but maybe it was a regional thing. "Spindle" gave me some trouble too -- I couldn't figure out what it meant exactly, until I remembered those things people used to jam papers, invoices and (apparently) cards on to. Yep, that would be a problem.

tom
tom

As a student in '76 I remember writing a program "gooble" Its sole purpose was to replicate itself until the system ran out of space. It had a short life as the system had hard limits on memory.

TOAB
TOAB

On our old Unisys 1100-80 the Big Red Button was a push style. It managed to be hit a few times during my 10 years there. Management even tried putting little perspex covers over the button, but it didn't help. (We convinced managment the switches must be faulty) The deafening silence in the room was amazing (until the Shift Manager started screaming at us.) The bad point was the flashing lights on the STU all went out :-( The main cause of button depression was the playing of cricket, baseball and/or softball in the room during the quiet periods.(Cardboard bats and packing tape balls) When power was restored and the disk drives were started up again, I enjoyed the gentle waft of peanut butter comming from the drives with head crashes...

goliva
goliva

Didn't matter what mainframe company it was, carriage control tapes were a PITA. And don't forget warning the Operator trainee never to leave a disk pack on top of any printer even for a few seconds. Paper runs out, cover opens up, and disk pack now useful as a curling stone??

Henriquez
Henriquez

My first computer experience was also APL, delivered by terminal to my high school in Boston from IBM's place in Armonk, NY. We got to go there once on a field trip. :)

bobc4012
bobc4012

Now APL, great language - that and running it on VM (nee CP/CMS). Two great products that IBM never marketed - didn't sell "BIG IRON"!!! To this day, I have never heard of an IBM VM system being hacked, getting a virus, spyware, malware, etc.

pflapham-23737826629493199154303227527571
pflapham-23737826629493199154303227527571

Back in '81, I had a 9 page presentation designed for display on computer monitors. It worked beautifully at our site. However, when we went to the client, their connection was 300 baud. There was nothing more agonizing than watching the cursor plod across the screen - row by row, character by character. :~ Thoughts of 'Will we be able to sell this to them?' coursed through the brain. Fortunately, the client was very patient. We did sell it! But I learned, that day, to always view things from the Client's point of view. :) It's helped my code design and development to this day.

NickNielsen
NickNielsen

If the victim doesn't have a sense of humor.

NickNielsen
NickNielsen

The common words in every warning were fold and mutilate; I don't remember ever seeing bend. Some said "Do not fold, spindle, or mutilate" while others said "Do not fold, staple or mutilate." Apparently, although there were numerous ways to damage the cards, folding and/or mutilating were the most horrendous.

CharlieSpencer
CharlieSpencer

You mean those big spikes like greasy spoon restaurants use to store the customers paid tickets? I always wondered what that meant. Who says this place isn't a repository of (useless) knowledge?

NickNielsen
NickNielsen

When one got too grungy, put in a spare and clean the old one when you get the chance. I loved the Mannesman-Tally band printer engine. If you kept it clean and lubed, it was solid and reliable, with almost never a mechanical failure. That engine was the innards of every 600-line RLP I ever repaired. edit: The repairs were board replacements!

Henriquez
Henriquez

THAT's what they looked like! Wonder if anyone ever tried it?

Robiisan
Robiisan

I learned the same lesson. :-)

ziffdavis
ziffdavis

I used to have remote access to the mainframe over a 300-baud acoustic coupler and keyboard box that connected to my TV for a display. The problem was the darn thing generated so much heat that it would die inside about 15 minutes on a hot summer's day (and my apartment was not air conditioned). My solution was to put the coupler-keyboard box in the refrigerator and pre-cool it, to give me up to an hour of connect time before it failed. Aaah, technology and kludges!

seanferd
seanferd

I just mashed all the specific warnings I could recall into one. I don't suppose it would be a good idea to stuff Hollerith cards into certain places, either. :0 I've never seen a warning about not getting them wet and/or sugary, but that would be bad as well. Same warnings apply for Scantron-read materials, or anything someone decided to be picky about.

Henriquez
Henriquez

The perennially undervalued refrigerator approach. :)