When PC Still Means 'Punch Card'

ricst writes: "The New York Times reports that there are stll many applications that use punchcards. "Use what?", you say. Slashdotters not yet in their dotage may have never seen these 80 column Hollerith field cards, or the clunky machines that are still used to punch holes in them. And let's not forget the bizarre JCL (Job Control Language) that's needed to be at the front of the deck. Well... turns out many companies still use them, with slight modifications (like the airlines that print a magnetic strip on them)."

Comments

Hotels

[pokka]

I often see punchcards being used as keys to hotel rooms. Does that count?

Engineering uses

[FastT]

At least in the automotive engineering field, punchcards and Fortran seem to still be going strong. I remember when I got my ME degree in the early nineties, we had photocopies in our handouts of the punchcards used to calculate flame propagation for combustion engine design. Interestingly, the programs companies and researches use for these calculations are written in Fortan.

Re:Engineering uses

[edhall]

The amazing thing about the first touch-tone dial is that it used a single germanium transistor to generate both tones. (Transistors were pretty expensive at the time.) Let's see some of today's EE's figure out how to do that!

But back to punch cards; one of the reasons old farts can get misty-eyed over such obviously inferior technologies is that, in some respects, it's damned impressive that they worked so well. A card reader that can read more than a hundred cards a second is a remarkable piece of machinery, and is impressive to see (and hear -- they're loud!) even today. Sure, a CF card smaller than my thumb holds 670 times more data than the 5000-card trays that they fed into these monsters. But computing has lost the visceral element it once had, and from a mechanical engineering standpoint is a lot less impressive.

-Ed

Are you old enough to remember..

[Innominate Recreant]

the expression "Batch is a bitch" or "Floor Sort"?
Until fairly recently (3 years ago) at a VAX shop I worked at, they used VMS software that emulated an IBM RJE (look it up) station for transmission of financial transactions to a bank. Each record in the file that was sent appeared to the IBM mainframe to be a punch card. I had to write a DCL routine to create the JCL that launched the program remotely on the mainframe.
Banks are always the last institutions to adopt new technologies.

Inominate Recreant - 22 years in the code biz.

Re:I see

[coyote-san]

Actually punch card ballots solve a number of real problems. They're tangible, they can audited, they can be repeatedly recounted, they can be archived. Heaven help you if there are problems with some of these "improved" systems.

But punch card technology covers everything from the heavy punch used in my precinct (which takes a sizeable bite out of two-faced card - hard to overlook hanging chads) and the unmarked small holes produced with a stylus in the "vote-o-matic" system used in Palm Beach County, Florida. Our system isn't perfect, but it's hardly an indefensible anachronism.

Non-Volatile Memory

[Aging_Newbie]

Given temp and humidity control the program stored on punch cards will withstand almost any assault including thermonuclear EMP. That's why paper tape is still the program storage method for some really critical systems. It is very hard to erase a punched hole.

Re:.net?

[bunyip]

Why not? Just gotta port an interpreter.

In fact, I have a simple JCL interpreter for Linux. I read someone whinging one day that Linux was hard to use. Methinks, "hard to use, I'll show you hard to use!" Imagine 14 lines of JCL to call IEBGENER to copy a file....

Porting it to C# / Mono would somehow be wrong. I've done enough wrong already.

MILSTRIP

[theNote]

I write software for the government that users a spec called milstrip.
Altough we don't print out cards, transactions between government/military systems still use 80 character long messages (or milstrip).

The milstrip spec is actually quite useful, and complex.
Although they are based on a legacy format, 80 character based systems have had an incredible amount of time to mature.
Replacing them all with more recent fromats (ie XML) would really give no return on investment.

Re:Use JCL to stop junk mail (postal)?

[MaggieL]

Not so much someone named //SYSIN DD * (which a stream starting with //SYSIN DD DATA could cope with, but rather somone named simply /* would be good. In any case, a well-coded "DLM=" parm would be a help.

Every once in a while someting stirs these old memories and it makes my brain hurt. I once had an ISPF display in a window on the same desktop with some Java source code in another window and my ears started to bleed.

Old Timer Story

[dhovis]

When I was in high school (10 years ago or so). I went with my father (a CS prof) to some seminars. There we met and talked with some old timers who'd been working with computers since the 50s. They told us about "code libraries" starting back in the days of punch cards. The story went something like this:

Bob: Hey Joe, didn't you write an I/O routine last week.

Joe: Yeah. [Joe pulls a stack of punch cards down off a shelf with a rubber band around them, and hands them to Bob.]

Bob: Thanks. [Bob removes the rubber band and inserts the stack of punch cards into the program he is writing.]

Re:Use JCL to stop junk mail (postal)?

[gd23ka]

The statement maps the symbolic file reference SYSIN as it is known in the program(s) to be run by the job step to a file '*'.. It's been years that I had to fsck around with JCL but '*' might mean input from the reader or maybe a terminal device.

Re:What's so different about this and...

[CaptainCarrot]

Not so different if you're only thinking about applications like using them as timecards. My own company, a major Santa Clara Valey defense contractor, only gave them up a little over a year ago, replacing them with an electronic system that looks as if it were designed for Windows 3.1. They waited so long for much the same reason as many of the organizations mentioned in the article did: it was old, but it worked and it's therefore difficult to justify the cost of replacing the entire system.

The cards were prepunched with our employee ID numbers, the building and organization numbers, and a week code. Hours were recorded on the face of the card by handwriting, and were manually keyed in later by payroll staff. (It became very much an art to legibly write your charge numbers and hours around the holes.) Ultimately, I think it was the cost of maintaining a trained group of keypunch operators that only had real work one or two days a week that instigated the changeover.

Of course, it would be hideously impractical to use a punchcard as an ID card. They're just not durable enough to carry around in your walled and still last any length of time. But you're right: conceptually, for that particular application, there's very little difference.

The difference comes in some of the other applications mentioned. Your ID card isn't really a data storage format -- nobody ever considered storing mass amounts of data on stacks of ID cards -- but cards punched with Hollerith codes are both a medium and a format. They can store data, as the article mentioned with the old nuclear test data that's only recently been converted, or they can store code -- Fortran, for example, was designed to be used with punch cards and this is why Fortran IV was so rigid about line lengths, what information goes in what columns, and so forth.

I used them.

[Ymerej]

I was in the last class at the University of Illinois at Urbana-Champaign to use punched cards to submit our programs. I've always thought it was kind of neat that I had a taste of that technology.

At the time, I really resented having to learn how to use a card punch. I eventually learned that you could sneak into the lab in the next room, and use a text editor on a 24 line by 80 character terminal to create your program, and then have the program punched by an automated card punch. Then, you took the cards back, and inserted them into the card reader.

We had a certain amount of credit in our accounts, and when it ran out, that was it. No more runs. Yes, we did much more careful desk checking "back in the day".

Re:Seen them!? I punched 'em - still have a box ..

[puetzc]

Actuallly, punch cards are much older than 80 years. They were developed to tabulate the data for the 1890 census by Herman Hollerith (as in the hollerith code field(s) used in FORTRAN).

Another interesting fact - the cards are the size of a dollar bill. You don't think so? They are much larger? Punch cards are the size of an 1890 dollar bill.

Re:When I was kid.

[cgleba]

My father used to bring home stacks of those orange cards with the numbers on them when I was little.

They used to be a blast! Man, the card houses I used to make with those! Nasty paper airplanes, too :).

Apparently they became obsolete when his company upgraded to "round tape". A few years later he brought me these round plastic discs about 9" in diameter and hollow in the middle. Who needs frisbees when you have these! (appartently they had upgraded to "square tape").

Ironically all this talk is making me nostalic also. . .but in a much different manner. . .you're all decribing my childhood toys! :).

Man, I used to remeber going into work with him sometimnes when he was 'on call' during the week-ends. . .used to play with miles of scrap tractor-feed cut-offs as he bitched about a wierd thing called 'JCL'. It was better then plastic ball cages at McDonalds! I used to spend hours staring at the tractor-trailer sized laser printer that ran through a box of tractor feed in about a half hour. . .

He disliked it very much when I used to play "hide and seek" under the raised floor. . .even much more so then when I did the same with my mother in the round clothes racks :). . . later on he made good use of this habit by handing me a cable to snake while I was under there. . .

Man I only wish that I could have so much fun with such simple things today!

Then I wonder why I am a geek :).

Re:Cards?

[Peyna]

Heh, I'm not that old (19), but my first computer was a Tandy 1000 from radio shack, I think it had about 8 MB of ram, and I had to boot DOS 3.x from a disk to be able to play games like Flight Simulator and write programs in GWBASIC.

It does amaze me when I meet people my age or just slightly younger that have never used a computer without a GUI. Especially when they are computer science students.

We still use them...

[psi]

I work for Logistics Information and as a part of our job is to track past and present government contracts via RFQ, NSSN, and Cage codes. Some of them have been archived in Punch cards with embedded microfiche with Hollerith data. We read them in with an Aperture Card Read from Contex which cost a pretty penny. 12 Grand to be exact and very time consuming. Try 70 cards an hour. Now imagine a couple of cabinets filled with those little cards. We are currently trying to take all that data off the cards and put online, but takes forever to do. These probably were most effecient at the time they were used, but now there is a real push to get these in another format for easier archival purposes. My recommendation to anyone wishing to continue this fine tradition of making these cards... it is more effecient and less costly to go with another method, but if you insist on doing so... at least PUNCH them. I've run across thousands of cards that has great fiche data on it, but no Hollerith data on it at all. It one thing when your machine can't read the data, its quite another when there is NO data. Guess I'll go back to the machine and feed it another 70 cards and pray it doesn't eat them.

Virtual Punchcard Server

[RJM]

Who says you can't use punch cards today? Try the Virtual Punchcard Server.

Here's Some More Arcana:

[Anonymous Coward]

Standard IBM keypunches (during most of the 1960's with many still in use in the 1970s') did not type the letters on the cards when you punched the holes. There was a separate machine called an interpreter to do that. Take the punched cards and run them through the interpreter to see if you punched the right data. But -- the cards had 80 columns of holes, but the font from the interpreter was a little bigger, and only 62 columns of interpretation showed on the card! The only way to check if your cards were right was to keypunch them again in another machine called a verifier that would signal tilt if you tried to punch a hole where there wasn't already a hole.

In the mid 1970's, IBM finally introduced a keypunch that could actually remember an entire card of characters and had a backspace key and didn't punch the holes until you were sure that the card was correct. It was a godsend of sorts. Of course, many cards with errors were actually used intentionally. The errors were commented out.

There were 256 characters in the IBM EBCDIC character set, but no where near that many keys on a keypunch. Yet all the characters could be punched. You had to hold the card firmly in position so that it wouldn't advance to the next column when a key was pressed. Then, by overpunching multiple characters or digits, any of the 256 characters could be encoded. However, there are 4096 possible ways to punch a column of a card, so many invalid characters could also be punched. Abend!

Perhaps the greatest trick of the punchcard era was the trick of tossing a deck of cards, say a program that had to stay in order, across the room with no rubber band around it. There was a technique for doing this so that the deck would fly across the room in one piece. This required skillfully sliding the top and bottom cards off the deck as it was released into flight. Not for the timid.

The tab card equipment for computing from the cards was equally awesome. There were relatively simple machines that could add and subtract and print reports. These were programmed with plugboard where wires were inserted to connect input card positions to output ptint positions. But the real wonder was the calculating card punch that could multiply. When this thing was on, not only did the whole room warm up, the next room warmed up, too. Must have drawn about 10kw for all the firebottles.

Re:Use JCL to stop junk mail (postal)?

[Jay Maynard]

Every once in a while someting stirs these old memories and it makes my brain hurt. I once had an ISPF display in a window on the same desktop with some Java source code in another window and my ears started to bleed.

Well, you can now have your very own MVS system on the same desktop as your web browser...Check out Hercules.

JCL had one really advanced feature...

[Jay Maynard]

...well, at least as implemented in OS/360 and its descendants: device-independent I/O. The point of all of that was that you could redirect your program's input or output to any dataset (file, in modern terms for anyone who's not a mainframer), be it on tape, disk, card (reader or punch, as appropriate), or printer. This was NOT a Unix invention: OS/360 had it in the late 60s. (Other OSes may well have had it before that). The statement
//SYSIN DD *
is the same idea as the Unix < redirection operator. To change that input to a different dataset, all you had to do was change that one JCL statement; no program changes were needed.

Amazing Aperture Card systems for managing images

[billstewart]

My aperture card system was *much* faste rthan yours :-)

Aperture cards may seem an appallingly hokey kluge today, and they also did back when they were still current technology, but they really *were* amazingly practical. A 747 can't even *hold* the blueprints it takes to describe and manufacture itself if they're printed on dead trees, much less take off carrying them. But if you put the stuff on microfilm, you've got millions of little pieces of film that there's no way to manage effectively. Aperture cards gave you a way to manage and automate handling the film so that you could tell what was on an image without sticking the thing on a microfilm reader. That made it possible to open-source an airplane, because you could actually deliver all the information about the plane along with the plane itself. That's not strictly true - a fighter plane might not have cargo space even for the aperture cards. But the important problem was that every airplane was different, so you needed the prints to be able to do repairs or make replacement parts. Not just every model of plane, but every individual large airplane, because the mechanical systems, electrical systems, instrumentation, and even body parts were constantly being revised, and the building time for a 747 or a complex military plane was longer than the design cycles. Lots of parts also stayed the same across multiple planes, and you'd want to be able to produce multiple spares, but since every plane was different, it needed its data with it. And computers weren't big enough.

Back in the mid-late 80s I worked on a project that scanned aperture cards to translate them into computer media, because computers were starting to be able to manage that volume of data. The system had to read the Hollerith codes on the card, which were an index that said what the picture was, and then do a high-resolution scan of the image on the film onto a bitmap file, hand it to an raster-to-vector converter that attempted to extract line-drawings and text from the thing into a CAD/CAM data format, and store all the data in an optical jukebox - gigabytes were still pretty big back then :-) I forget if it was doing 900 cards/hour before I worked on it or after. I'd been brought in as a systems consultant because it was going dog-slow compared to what somebody had promised the Air Farce that they were going to be able to build, and it was way over budget and behind schedule, though of course the requirements hadn't been well-defined at the beginning of the project (except the number of cards/hour), there'd been lots of scope creep, the customer had changed the number of index fields in the database (seems like a minor thing for you relational database folks, but on a traditional mainframe database that was major surgery, especially when 10% of the cards had bogus data or had non-unique values in fields that were supposed to be unique sorting keys :-) Getting the people to redesign the mainframe stuff that was handling the database fixed the performance; the bottleneck should have been either the optical scanning process or storing the huge quantities of image data on the optical disk, not waiting for some silly CICS-emulator to look up the Hollerith data in a database so it would know how to label the image when it read it :-) The scanner system really rocked, and after the mainframe side was cleaned up, it was able to provide some of the performance we'd bought it for.

Re:Seen them!? I punched 'em - still have a box ..

[GSloop]

Yes, I didn't have the "opportunity" to use punch cards... [Groan] You could all see the "old" timer story coming couldn't you...

My prof in university told me of his first programming job. A payroll system. They didn't have a computer system yet, so they diagrammed and setup the program on punch cards. Then they took the completed program (punch-cards) and bought some spare time on another machine. After feeding the punch cards, the program ran correctly tbe first time!

Sheesh, and I ues a compiler as a syntax checker. When was the last time you got anything more complex than "hello world" to compile and run correctly the first time. (Ok, I'm a sucky programmer [grin]) But never the less, program design was a whole lot more rigerous then!

Thems were the days!

Cheers!

IBM, Punchcards, and the Holocaust

[omega9]

Now here's an interesting bit of history relating to IBM, punchcards, and the Holocaust:

IBM USA knew that its Hollerith machines were needed and used in concentration camps. IBM USA kept careful records of where its leased property was located and played an active role in servicing these machines, training its clients how to use them, and providing punch cards and other supplies. IBM USA's inventories of 1940 and 1941 indicate that the company knew which Hollerith machines were located in camps, along with their serial numbers and the amount they were being paid for the lease of each machine. At Dachau alone there were approximately 24 IBM sorters, tabulators and printers.

For more info, look here. The link is to a piece of commentary dated 2/19/01 posted on the site of a law firm specializing in class action law.

Punch Cards in the 1930s & 1940s used by Nazis

[SulphurFury]

Anyone remember seeing the numbers tattooed onto arms of victims of Nazi concentration camps in documentaries showing actual WWII film footage?

The films in black and white where a crowd of liberated prisoners stand with their sleeves rolled up, showing their number. Each one of those numbers corresponded with an IBM data punch card.
After the war, hundreds of thousands of these punch cards were discovered in the office buildings of the camps. In particular the Auschwitz camp in Poland, which is now a museum, now has on display these cards of victims who perished there. This comes at around the same time a book is published detailing IBM's role in the Holocaust, "IBM and the Holocaust: The Strategic Alliance Between Nazi Germany and America's Most Powerful Corporation" by Edwin Black.

The Nazis needed to be able to better select, sort, classify and track data on their concentration camp victims. IBM came in with their solution - punch cards were the medium used to store data corresponding with an ID number tattooed onto each victim's forearm. These punch cards were run through a Hollerith tabulator machine.
The Hollerith machine, which was used since the late 19th century to tabulate and alphabetize census data, made rounding up victims, tallying deaths, and overall organizing the war effort extremely efficient. For example, Hole 3 signified homosexual, and Hole 8 designated a Jew. This technology was a precursor, and was a basic building block of IBM personal computers that emerged in the 1980s. Technology that now is used to track, select, classify and sort people today - through the internet?

It makes me wonder why IBM initially didn't want to get into the home computer market and allowed companies like Atari and Commodore to have a crack at ruling the desktop. Atari and then Commodore both tried doing it with computers able to do advanced graphics and sounds. Yet Microsoft ensured the technology of the IBM PC would survive. The technology of the punch card in every user's home. Could it be some sort of conspiracy surviving through the ages?

Plugboards

[Animats]

I did quite a bit of work with an IBM 403 in high school. I knew how to wire plugboards for all the standard tabulating machines, and I even got an IBM 85 collator to generate poetry, which was then printed on an IBM 403. Still have the printout. I made up a "pattern deck", which contained a sequence of desired parts of speech, pulled from existing poems, plus some additional criteria. Then I had a big deck of words tagged with part of speech info, which I'd shuffle. Both decks went into separate hoppers of the collator, which read word cards until it hit a match on part of speech. The collator then dropped the matching word card into an output hopper and advanced the pattern deck by one card. Took about an hour to generate a few lines of bad poetry.

The 403 and 407 tabulators were basically Very Long Instruction Word machines. Cycles were slow (about one per second), but every register could do an add or subtract on every cycle.

Re:How fscking ironic!

[Rotten168]

Well, the system I used, we had to use a system which allowed little or no automation on things that could have been extremely easy on a modern OS like Windows or UNIX. Having to type in a 8 line sequence every night was tiresome.

viruses, trojans, hackers, crackers
Well maybe not viruses and trojans, but hackers and crackers are still very much possible. A disgruntled employee knows the password to admin so he logs in and types 'pend' for the hell of it.

EULAs Uhhhh well IBM still has a pretty fascist LA with whatever company is running the mainframe... this is proprietary in the true sense of the word, not what the /. ameteurs think the words means, the OS is tied to IBM and is leased and is subscribed to.

Microsoft
Ah, yes, this wouldn't be /. if you didn't slam MS in some way. I can't tell you how many times I wish I had access to a modern system that used heirarchical file systems instead of cryptic and badly written JCL and JECL statements.

BSOD
Our mainframe was poorly administered so occasionally it would not returned from answered partitions... meaning it had to be rebooted basically and the disk would have to perform a disk check like any other OS.

It means users using the computer to get the job done, not web surfing, playing minesweeper or struggling with the latest Outlook disaster.
Well whatever... it also means struggling to use a cryptic and antiquated system while real work could be accomplished on a mini or a pc.

It means hardware, operating systems, compilers and utilities debugged over nearly 40 years that work 7/24 without a hiccup.
Granted IBM hardware is rock solid... although our in house utilities sucked @ss, still a Sun SPARC will work running Solaris works just as well as the IBM mainframe we used. I'm not anti-mainframe I'm just staunchly anti-JCL, I'd rather flip burger than work with it again.

Sorry you lost your job
Don't be, I'm not. :)