Please create an account to participate in the Slashdot moderation system


Forgot your password?

When PC Still Means 'Punch Card' 456

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)."
This discussion has been archived. No new comments can be posted.

When PC Still Means 'Punch Card'

Comments Filter:
  • oh yeah... (Score:5, Funny)

    by doooras ( 543177 ) on Friday February 08, 2002 @09:41PM (#2977649)
    after enough holes get punched in your card you get a free sandwich, right?
  • As a friend asked me recently, I wonder how many applications could cope with someone named "//SYSIN DD *"
    • by MaggieL ( 10193 ) on Friday February 08, 2002 @10:08PM (#2977744)
      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.

  • .net? (Score:4, Funny)

    by hex1848 ( 182881 ) on Friday February 08, 2002 @09:44PM (#2977665) Homepage

    /me wonders if the .net interpreter can handle punch cards along with the 87 other languages it claims to be able to compile
    • (Score:2, Interesting)

      by bunyip ( 17018 )
      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.
  • I see (Score:5, Funny)

    by felipeal ( 177452 ) on Friday February 08, 2002 @09:44PM (#2977666) Homepage
    ...that there are stll many applications that use punchcards.

    Like the state-of-art US ellection system...
    • Re:I see (Score:3, Interesting)

      by coyote-san ( 38515 )
      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.
      • Re:I see (Score:4, Insightful)

        by danheskett ( 178529 ) <> on Friday February 08, 2002 @10:40PM (#2977830)
        You know what the best type of voting system is?

        Those sheets of paper where you connect the arrow for the candidate of your choice.

        Its non mechanical, the machines to read them are fast, very very accurate, they can be audited, there is virtually no room for physical failure (i suppose your pen could run out of ink, but it has a very good feedback loop), and little room for intepretative error.
        • by mpe ( 36238 )
          You know what the best type of voting system is?
          Those sheets of paper where you connect the arrow for the candidate of your choice.

          Most parts of the world use a system like this. Though in some places it's common for the ballot paper to have pictures of the candidates. Even the illiterate can recognise a picture and place some sort of marking adjacent to it.

          Its non mechanical, the machines to read them are fast, very very accurate, they can be audited, there is virtually no room for physical failure (i suppose your pen could run out of ink,

          Hence a soft pencil is typically used. Which is less likely to fail and is obvious when it need sharpening.
  • by Ieshan ( 409693 ) <ieshan&gmail,com> on Friday February 08, 2002 @09:44PM (#2977667) Homepage Journal
    the magnetic card my university gave me?

    It's really the same principle. I carry around a data representation of who I am, and to verify it, they swipe my data through a little machine before they let me eat, etc. Most of the time, they don't check the face, don't counter-check the name, don't do anything. In fact, I could go eat as most other white males (they'd probably notice if I gave them an african american girl's card, they aren't THAT slow. ;))

    But really, what's so different? We haven't moved to a much better system yet, even though fingerprint ID is readily and widely available, wouldn't require me to carry around an ID card, and wouldn't require the lady who has to swipe my card for me (really, a silly expense for the university).

    Just seems like "modernization" needs to happen in concept as well as "tech", and that it isn't.
    • The difference is that punch cards actually are the data. Your university ID card or my drivers license or credit card only contain enough unique info to allow a positive match to the data on the server side.

      How many megabytes do 80,000 punch cards represent? I wouldn't know where to start the math, but I suspect that if you took 80,000 university ID cards and added up the server side data the university stores for each individual you'd have 1-2 megs per student and I bet a punch card doesn't hold that much!

      • and added up the server side data the university stores for each individual

        If this is how you're going to calculate data stored (which is a mistake, IMHO), then punch cards do indeed "store" just as much as magstripes.

      • IIRC, the standard IBM punch card was 80 columns by 12 rows. Using the standard ISO 1682 encoding, alpha characters were represented by 2 holes -- 1 in the first 3 rows, the second in the last 9 rows, while numbers were encoded as a single hole in one of the bottom 10 rows (0-9). [The program bcd(6) will print out an ascii-art representation of a punch card. It is part of the bsd-games package]. You will note that this takes 12 bits to encode a single monocase alphanumeric character -- very inefficent, but necessary because putting more holes in the card would cause feeding problems, at least with 1970's era paper-handling machinery.

        Therefore under ISO 1682, each card holds a maximum of 80 bytes of alphanumerical data; binary data would have to be uuencoded, which would only allow 60 bytes per card. 80 bytes times 80,000 cards is 6,400,000 bytes. Divide by 1048576 bytes per meg and you get 6.10 MB.

        • Therefore under ISO 1682, each card holds a maximum of 80 bytes of alphanumerical data

          Which is a good chunk of the reason that most monitors and printers had a width of 80 (or 40) characters. It was even listed in the documentation for (I believe it was) the Epson MX-80.


    • by CaptainCarrot ( 84625 ) on Friday February 08, 2002 @10:26PM (#2977797)
      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.

  • Hotels (Score:2, Interesting)

    by pokka ( 557695 )
    I often see punchcards being used as keys to hotel rooms. Does that count?
  • Technologies, in society, operate on a gradient. The old ones are usually retained until they fall apart, and the new ones are acquired when it's forced upon a business or an individual (usually because everybody else has acquired a new tech, and it's incompatible with the old).

    There are vested interests in old technologies, too. That's why an airport, who's been subcontracting to an old-skewl tech company for years, may have a new iteration of punchcard tech.

    In Africa, for example, the old Datsuns and 286's we throw away are put to good use, and repaired until they fall apart. Most people, there and here, see technology as a necessary evil, not a blessing. They would hate to spend money on, and waste time learning, something new just for its own sake!

    Only a truly myopic perspective - that which worships the new for the newness, and hence also worships the old for its oldness, would consider the use of Punchcards something slash-worthy. I wish there were more perspective on these issues.

    • by 2Bits ( 167227 ) on Friday February 08, 2002 @10:03PM (#2977727)
      Hey dude, upgrading for the sake of upgrading is how you make the economy move. Beside, the US president is asking people to go out and spend money, it's an act of patriotism.
    • What an insipid posting. First of all, why qualify your discussion of technology to "in society," as if the discussion would be different if we were speaking about technology "outside of society"? What would that mean?

      The "gradient" analogy is likewise facile. The line you draw is one-dimensional. What of other dimensions, such as exotic-ness of technology, societal cost, or economic gain? For example, the nuclear weapon is, by your standards, "old technology", yet it is certainly exotic and its age renders it no less consequential. A more thoughtful view might suggest that enonomic forces, not the "falling apart" (your term) of technology drives the adoption of new techniques vis-a-vis technology. I doubt that the "old-skewl" airport has much of a vested interest in punchcards for their own sake. Rather, the magnetic strip/punchcard approach best meets the current requirements of the airline busiess. A business, which, I might add, is hyper-competitive. I doubt that a conspiracy of "old-skewl"ers lurks behind the ticket counter. They would be non-competitive and quickly forced out of business.

      All of which leads into my final point, your most vile line of reasoning, shared by those who prefer pulse dialing to touch-tone and typewriters to word processors. What rubbish! Do you expect that those 286's and Datsuns, deployed in the Western economies, would aid an enterprise that must compete and produce in the marketplace? I should think not. At what point do you draw your arbitrary line in the sand - why the 286? Why not the Z80, or better yet the abacus? A sneering, pile of blather, your post. It makes my heart ache for your poor keyboard, whose keys are that many presses closer to the end of their design life for no good reason at all. Doubtless though, you shall at that point send your partially-functional keyboard to Africa, where it shall be used to great gain by one of the many world class businesses to be found on the plains of the mighty Serengheti.

      You miss the point of the discussion in your rush to be dismissive and rude to the rest of this community. Myopic indeed. -Marbury

  • Engineering uses (Score:3, Interesting)

    by FastT ( 229526 ) on Friday February 08, 2002 @09:47PM (#2977676) Homepage Journal
    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.
    • Even in a field where no actual cards have been used for 20 years, the documentation for a lot of the scientific code that I deal with still uses the word "card" extensively to mean "line in input file." The vocabulary just hasn't caught up with the technology...
      • Or how about 'taping out' a chip design. Are they still delivered on magtape? Or do they burn a CD, or transfer a file electronically?
  • Let's face it -- there are some times when cheap and portable is what matters, and low density just doesn't matter. Whether or not at that point you use puched paper, bar codes or magnetic strips is mostly just a matter of your application. Personally I suspect that bar codes is actually the main competitor to punch cards in this application, because they can be produced on standard laser printers (a fairly new development, mind you), however punch cards do have one major advantage over bar codes or magstrips: it's probably the less fragile of the three.
    • What about smart chips? I believe those are a pretty good, too. (Data is stored in static RAM)

      I've put one through the wash and run it over a magnet. No effect. Plus, they can store a little more than any of the other things you've mentioned (and they are cheap, too).
  • I always found the punch card stories my professors told to be about as enthralling as the "I walked through snow barefoot up hills, both ways" stories my grand daddy told me.

    Both are of equal value. (ie, whine = whine)
    • Re:When I was kid. (Score:4, Interesting)

      by cgleba ( 521624 ) on Friday February 08, 2002 @10:46PM (#2977856)
      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 :).
      • The 9-track magnetic tape technology let you write-protect or write-enable tapes by inserting or removing a plastic ring that the tape-readers checked for before writing. There were usually lots of spare write-rings around any computer shop, because you'd remove them from backup tapes you were archiving so nobody'd overwrite them. They were great toys for little kids (good to grab or chew on), and also made good cat-toys.
  • by Innominate Recreant ( 557409 ) on Friday February 08, 2002 @09:50PM (#2977684)
    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.

    • Heck, I'm old enough to remember when the Alpha Operator in the computer room was the guy who could pick up a whole stack of punch cards out of the tray to load into the reader in one shot as opposed to taking several baby hand-fulls one at a time.

      You had to press the stack together hard enough so that they would not slip and fall to the floor, but not so hard that the stack would buckle and explode in your face.

      Mind you, this is also why you would take a marker and run a diagonal stripe down the top of the stack of cards so that if you dropped them you could get the 400 - 600 cards of the run deck back in order. Sequence numbers! We don' need no stinkeen sequence numbers!

      Of couse the real benefit of working as a third-shift tape ape in an old fashioned mainframe shop was that you could keep a six-pack of beer cold under the raised floor and drink as the register lights flickered and the tape drives spun.

      As to the fellow who spewed blood seeing JCL and Java on the same screen: happens to me every day at my current assignment.

      Old dog learning new tricks!

      • JCL 'n' Java (Score:2, Informative)

        by rogueroo ( 242539 )

        A project currently underway with my employers is to take data from a web input form and use it in a batch program on the mainframe. The web server runs under UNIX System Services. Java applications have been written to parse the input data, reformat it, and to pass that data to the OS/390 batch JCL.

        I don't know a whole lot about the Java side of things -- I'm responsible for the UNIX System Services and OS/390 system environment.

        I guess what I'm saying is I don't seem to have this blood loss problem.

    • 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.

      D*mn. We got rid of our VMS RJE (Remote Job Entry, for those who don't want to look it up) card-image submission queue several years ago. We started FTPing the card-images instead. :-) Much more advanced! Of course, this was very much a case of "if it's not broke, don't fix it". The application ran without problems for about 10 years.

      Recently, the applications in question have been replaced with directly loaded Oracle DBs.


      (Who has several boxes of punch cards in his basement from his college days. And who wonders if anyone remembers the 96 column punch cards!)
  • Cards? (Score:4, Insightful)

    by saintlupus ( 227599 ) on Friday February 08, 2002 @09:51PM (#2977691) Homepage
    slashdotters not yet in their dotage may have never seen these 80 column Hollerith field cards

    Hell, seems like most Slashdotters don't remember the heady days of the 486 any more, let alone punch cards.

    "You mean computers used to have just a command line? Not even Windows 95?"

    (I know, I know, troll. Fuck off.)
    • Re:Cards? (Score:3, Interesting)

      by Peyna ( 14792 )
      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.

      • I keep the machines working in a public school district and walked in some kids playing a ShockWave game. The game was a tank game with green vector graphics and even had the volcano on the horizon. Of course, it had a lot of so called innovations like powerups but they looked at me quizically when I said, "Hey this is basically BattleZone." They were members of the school's geek squad too. Kids these days :-).
      • Peyna wrote:

        > 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.

        I'm not exactly in my dotage (38) but I've seen and worked with punch cards. In the summer (1980) between my junior and senior year in high school, I got to go on a student research trainee program at a university. They had a Burroughs (sp?) mainframe that ran on cards, which was how my professor ran his Fortran programs back then. They also had a Honeywell system that had terminals, only they had just a printer for a display, and a keyboard for input. By the end of the summer, the new IBM 370 mainframe came in, and I saw CRT terminals for the first time. During some of my free time, I spent hours on the system playing StarTrek (it was the first computer game I ever played).

        By my senior year at that university (1985) the future had really arrived. There in the university book store, sitting on the counter, was the very first Apple Macintosh, complete with mouse!

        "Lightning shines on wavey beach, and all clouds are made right:
        Happiness Appears!"
        From the song "Infant Girl" in the Japanese version of Mothra (1961).
  • instead of post-its.


  • by gnetwerker ( 526997 ) on Friday February 08, 2002 @10:00PM (#2977716) Journal
    I don't mean to be an old fart of the "I walked ten miles to school uphill in the snow" variety, but it might benefit /.ers to remember that they didn't invent computers, software, or much of the technology they gleefully use and (?) misuse.

    Hollerith cards are ~80 yrs old, the stored program computer is > 50 yrs old, the Internet is > 30 years old, the PC is > 25 years old, and all the important user-interface functions we now use (windows, icons, mouse, pointer) were demonstrated in 1968 by Doug Englebart (

    I used to hate the comment that "I don't know what progamming language I'll be writing in 20 years, but I know it will be called FORTRAN". Now I see the (only slightly inprecise) wisdom in it. You would probably be bored by my stories about entering PDP-11 code on the console switches in octal, but there is a lesson in there somewhere.

    The message is: real change takes a long time -- one or two human generations. Overnight sensations and revolutions are usually many years in the making. Don't respect yer elders, but at least know what we did wrong. Andy Warhol said: "They say time changes things, but actually you have to change them yourself".

    End of Sermon


  • by superid ( 46543 ) on Friday February 08, 2002 @10:01PM (#2977719) Homepage
    ....sitting at the 029 saying "someday they're gonna bury me face down, 9 edge first"


  • Non-Volatile Memory (Score:4, Interesting)

    by Aging_Newbie ( 16932 ) on Friday February 08, 2002 @10:02PM (#2977722)
    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.

    • by Tony-A ( 29931 ) on Saturday February 09, 2002 @12:02PM (#2979243)
      It's very easy to erase a paper tape.
      Just hold down rubout. All holes punched.
      Ever wonder why hex FF never gets a printable character?
      • by dvdeug ( 5033 )
        Ever wonder why hex FF never gets a printable character?

        Hex 7F (all holes punched in a 7 bit system) doesn't get a printable character, at least not in ASCII. But FF is a printable character in a lot of character sets - Latin 1 has ÿ in that spot.
  • MILSTRIP (Score:3, Interesting)

    by theNote ( 319197 ) on Friday February 08, 2002 @10:05PM (#2977736)
    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.
  • by PapaZit ( 33585 ) on Friday February 08, 2002 @10:06PM (#2977739)
    Wired magazine talked about this a while ago. The archived article is here []
  • by phraktyl ( 92649 ) <(wyatt) (at) (> on Friday February 08, 2002 @10:06PM (#2977740) Homepage Journal
    This reminds me of my Air Force days, when I heard many stories of how the Data Center admins would bring in a large bag of chad and dump it on the table in front of the new guy. They would make him sort it into Classified and Unclassified piles, with the Classified chad being anything with a marking on it. After several hours of tedious work, someone would run by and the breeze would mix it all back together on the table, making the poor Airman do it all over...

    I was told that very few realized that they could just treat it *all* as Classified, and burn it. Heh.
  • by TheMatt ( 541854 ) on Friday February 08, 2002 @10:07PM (#2977742) Homepage Journal
    Can't believe I didn't see this link: Free Punch Cards []. I especially love the graphical punch your own card.
  • Old Timer Story (Score:5, Interesting)

    by dhovis ( 303725 ) on Friday February 08, 2002 @10:10PM (#2977754)
    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.]

  • We had stacks of them in the lab I used to work in.

    We called them "incremental height adjusters".

    Very useful.
  • I remember decoding punch cards by hand when I was in Kindergarten in the late 1960's. My father was in the military, and we lived on an army base in Germany. He would bring home from work stacks of old punch cards for me. It was simple - one column for each digit and letter. I remember it was kind of cool how people's names and other recognizable words would emerge from the holes on the cards.
  • In college, in, oh, 1995, we had some COBOL classes. And the IBM COBOL interpreter we used had the column constraints; it considered text input to be a virtual punch card; various COBOL bits had to be in various columns, or it would not compute. The VAX compiler, fortunately, didn't have such constraints. But the teacher, who was 65+, kept a whack of card sheets, which he'd photocopy and hand out, and require at least one assignment done on.
  • I used them. (Score:2, Interesting)

    by Ymerej ( 12280 )
    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".
    • We had two different accounting systems for mainframe access at Cornell in the mid-70s - the "instant turnaround" system that was accountless and gave you one second of CPU time and some number of pages of printout, and the regular account-based system that let you access more resources, such as files stored on the disk system and unlimited printout, and more computer languages. I think it was HASP, but it might have been JES2. Computer classes used IT for the first couple of semesters, and then used real accounts for the more complicated classes or for real research. Most classes handed out a couple of accounts, or had group projects that gave you access to multiple accounts, or you'd have some classes that didn't really need most of the funny-money in their accounts so you'd have some money left over, and each class normally had a few extras (people dropped the course or whatever) that you could guess the default 4-character passwords for.

      The trick was to manage the accounts so that by the end of the semester, when crunch time came, you had a few accounts left that had at least a few cents credit in them, so you could exploit the Big Debugging Run Hack. Because the accounting system checked your balance when you started your batch job, to see if you had money and permissions that you needed, and debited the account at the end of the run, if you had any money left in it, your job could run as long as it wanted and print out as much output as you wanted as long as it could avoid crashing, leaving a negative balance if you overran it. So the desperation mov e you'd save for the big project was to get it mostly running but still containing the last few nasty bugs you hadn't been able to find, so you'd turn on all the gory debugging print statements around the sections you were having trouble with and burn a low-balance account. Then you'd take the reams of paper, spread it all over a table with different colored highlighters, and you and your project team would go hunt through and find the bugs, clean up anything else you needed for the hopefully final production run, and go run it from the real account. Hopefully that would work, or if it failed, then hopefully you had a few cents left in the account to do another run.

      Later, at Bell Labs, I became a TSO wizard and could do interactive compilation and debugging - much nicer than batch. And we had Unix on PDPs and Vaxen, and then they got Unix running on the mainframe - while it was still in beta, I could do my development on a Vax with 40 other users, or on a mainframe that had a couple clunky things but gave me 10 WHOLE MIPS of horsepower to compile with :-)

    • 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".

      Indeed. I sometimes wish I had started programming on that kind of equipment and thus would have been forced to develop excellent code debugging habits. I'm ashamed to admit I rely far too heavily on runtime checking :( But I'm trying!

  • JCL (Score:3, Funny)

    by Registered Coward v2 ( 447531 ) on Friday February 08, 2002 @10:35PM (#2977818)
    One of the advantages of JCL was you could put a few cards at the front of your deck that said "please do a warm boot" so someone couldn't run a program before you that caused all subesquent programs to be read as data an print mindless gibberish as the "output".

    Nest week: Switching the run and parity error light covers on an 1130 for fun and profit.
  • Remember, with Open Source, you can re-write the code on anything. Imagine the possibilities [].

  • We still use them... (Score:3, Interesting)

    by psi ( 80552 ) <(psi29a) (at) (> on Friday February 08, 2002 @10:59PM (#2977901) Homepage
    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.
    • 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.

  • ... when we had to carve our own PCs out of wood!

    In my high school (this was in 1972 for you young whipper-snappers) we had an IBM-1620. In our programming class, we used Fortran-2D and punch cards. I wrote a random-word generator that ran the poor old 1620 out of memory!

    It was a Big Deal when we got a paper-tape reader to load the operating system with. Only took 10 minutes to boot instead of half an hour.

  • by brer_rabbit ( 195413 ) on Friday February 08, 2002 @11:13PM (#2977942) Journal
    I mean, anyone who relates to this story is probably in bed asleep already. ;)

    • by s390 ( 33540 ) on Saturday February 09, 2002 @12:30AM (#2978100) Homepage
      I mean, anyone who relates to this story is probably in bed asleep already.

      Wrong, you're only exposing your own stupid ignorance of serious mission-critical systems, cognitive ergonomics, and how industrial strength computing actually works.

      Although most physical punch cards were replaced by magnetic media about twenty years ago, give or take a few, "card-image" control and program files still run 80% of the large systems in existence - government, banking, insurance, credit-cards, drugs, consumer products, transportation, heavy manufacturing, distribution, retail, etc. The 80-column paradigm is alive and well, and it's not going to go away any time soon. It's merely been extended, but we still think in terms of "lines" of source code, don't we?

      Most source-code is still written in a 72-column or 80-column format. Where do think that came from, eh? The ergonomics of composing and reading code are still as valid now as they were then, when the punch card format was defined. Damned puppies! No respect for the technology that runs your world. Too 37337 to learn anything. Bah!

  • by RJM ( 25342 )
    Who says you can't use punch cards today? Try the Virtual Punchcard [] Server.
  • by Anonymous Coward on Friday February 08, 2002 @11:30PM (#2977981)
    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.

  • ...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.
  • My first computer was an IBM 403, which was really a big hulking printer that was programmed by a plugboard full of wires on the side which controlled what fields from the punch-card reader went into what fields on the printout and a paper-tape with holes in it that controlled when the print hammer hit and when the printer shifted the paper up a line. The printing mechanism was 133 vertical bars with the entire character set on each - they'd slide up and down to line up a line of characters and the hammer would hit them so they'd print a line of text. Paper slides, bars shift hammer hits, and usually each punch card would correspond to three lines of printout (address labels, etc.) plus a three-line blank shift.

    We weren't allowed to mess with the plugboard, only with the paper tape and the keypunches, so our programming mainly consisted of mapping fields between punchcard columns and the printout based on what the current plugboard did, programming keypunch drums to make it easier to get the right inputs into the card fields, and finding creative ways to use the card sorter to get the information we wanted while minimizing the number of times you ran the deck of data cards through the sorter. (That wasn't just because it's cool to be algorithmically efficient - it was primarily because if you put 1000 punch cards into the sorter, you'd usually get about 998-999 of them back intact and have to dig the pieces of the torn ones out of the mechanism and then retype them :-)

    A punch card sorter is an interesting beast on its own. It's basically a stable bucket sort - you pick what card column to sort on, and it sorts the cards into bins based on the letter or number in that column of the card. So to sort a deck of cards alphabetically based on a given field, you'd sort them by the last column in the field, restack into one deck, sort by the n-1th column, restack, ... until you've sorted by the first column in the field. So laying out fields on the card corresponding to the behaviour of the plugboard and figuring out how to structure the data you put in it was more complex than it sounded, because it interacted with the sorting you'd do on the card sorter (Do you want to sort the deck by zip code for mailing? Or alphabetically by name so you can check off people who attended or voted at a meeting? Or do you want to sort by town so people can do local meetings, or sort by skill set to tag people for committees or projects, etc.)

    My next computer after that was in high school - a PDP-11 running RSTS-11 and BASIC that we accessed by timesharing on an ASR-33 teletype, complete with paper-tape. Then the first couple years of college were a step back into punchcard-land, though at least there was a mainframe behind it and not just a mechanical smart-printer. *It* finally had JCL, which was rabidly lame after using the PDP-11s :-)
    It was a couple of years before I got back to terminals (whew! VM/CMS!) And the summer job with an IBM System/34 (48K of RAM and a disk drive and an operating system that was a dim ancestor of the AS/400). And then there was the Plato nationwide computer system, which had graphics terminals with a "notesfiles" system that later influenced Usenet and had really cool spacewar games. And then in grad school there was Unix and microcomputers running APL and all sorts of cool stuff. And then I used mainframes again, but seldom with punchcards, then Unix again for a couple of decades. Eventually I used this MS-DOS thing - it wasn't as primitive as JCL - looked more like VMS without the HELP system or any of the useful commands, which felt enough like RSTS-11 to wade around in.... And eventually there was Windows, which was sort of like a Macintosh implemented really badly on an unreliable operating system that didn't have enough resources and had applications that all worked differently and couldn't operate with each other, so there was none of the friendliness and knowing-what-to-do-ness of the Mac and none of the ease of use or power of Unix shell pipes and scripts. But at least it didn't feel like JCL.

    • Plugboards (Score:3, Interesting)

      by Animats ( 122034 )
      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.

  • Apu: "Here is the most intelligent tic-tac-toe game ever made!" <holding a
    box of punch cards>
    Bart: "What does....THIS card do?" <pulls one out>
    Apu: "Oh, well." <throws box over his shoulder>

  • In the NYT article, it states:

    "Although data in many different formats was encoded on punch cards over the years, much was encoded in the standard Ascii text format and can easily be transferred to modern computer files with the right equipment."

    Maybe I was hanging out with the wrong people in my youth, but all the punchcards I pounded out were EBCDIC.
  • Anyone out there will to 'fess up to adding a GOTO command at the end of every card pointing to the next card.

    It was really cool! You could shuffle the deck, and the program would still run just fine...
  • by omega9 ( 138280 ) on Saturday February 09, 2002 @01:19AM (#2978203)
    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.
  • There's a whole system still based around the punch cards. The cards don't exist anymore, but WYLBUR still acts that way. It's viewed as another computer system by the undergrads. I think at one point (92?) they were trying to incorporate email. Just figured I'd throw that in there. As a user, you really wouldn't notice, except that you HAD to obey the 80-character rule. And since they were teaching COBOL and FORTRAN and the like on it, the JCLs all kinda made sense. Hmmm....
  • 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?

  • Great Joke (Score:4, Funny)

    by Peridriga ( 308995 ) on Saturday February 09, 2002 @05:25AM (#2978643)


    I've always loved that joke....

"The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972