• Dinko (unregistered)

    Punch cards were not only carrier of program code but data entry as well. Card taken out of stack may have been one transaction. Now, this story does sound as an urban legend: Programs were not re-punched every day, just when change to a program was necessary or due to wear and tear. Program decks were reused and error in report would not limit to one day in a week and would ultimately crash the program, eventually (for randomly removed line of code). Missing one of the cards in data deck would be obvious causing a lost entry in printed report. Independent of media used (cards, tapes, discs), data processing in main-frame era was very particular about data safety and integrity.

  • Ken McLeod (unregistered) in reply to Otis P Criblecoblis

    Not to mention the JCL ... <G>

  • masterlock (unregistered) in reply to d000hg

    Agreed. A small company is going to have one or two cleaning people in house and can easily tell them where to go and where not to go.

    And a company large enough to afford an outside cleaning service should be able to afford a lock.

  • Justin Wielly (unregistered)

    Dude, I have not seen one of those old computer cards since like 1981. Wow that was pretty intense.

    JT http://www.Ultimate-Anonymity.com

  • david (unregistered) in reply to FunkyShu

    We used punched cards for everything.

    Also, I kind of wonder if you have ever done any cleaning?

    But each column only had a single hole, and most data cards were at least half empty. It's a characteristic of fixed-format data: the card has to be big enough for the longest data, not the normal data. There may only have been 6 tiny holes on the card.

    IBM changed from square corners to round corners in 1964, but there were still old cards and examples from other suppliers around in the mid 70's.

  • glt (unregistered) in reply to Otis P Criblecoblis

    As a grad student, I once had to be a TA in a COBOL course. Naturally, I was informed of this at least two weeks in advance - so I decided to write some sample code to figure out how COBOL worked. I decided to write a solitaire program (none of the business type programs in the text appealed to me), so wrote a random number generator, a shuffler and a dealer. This was in the good old days of mostly batch processing, we'd moved forward to the point where we could actually enter code through terminals (barely), but jobs were still built as batch runs on cards, though the cards could reference a file on disk (my COBOL source, for instance) and generated paper output. This meant that compiling and running a program, then figuring out what the output meant was typically fairly painful and cost money (funny money in the CS program but you'd have to justify getting more when you needed it) so you did it as infrequently as possible.

    Piles of COBOL code and finally time to compile and run. Got my output. At least a box of paper (before the operators turned it off)! The folks at the window (where you submitted your cards and got your output back) were not happy.

    Turns out I'd spelled "ENVIRONMENT DIVISION" wrong and every line after that had generated maybe 20 or 30 lines of error messages.

    It would have been cheaper to compile it many times than to pay for the paper.

    They made it much easier to run everything (and see the results) on the terminals not long after that.

  • Shinobu (unregistered)

    Perhaps it would be better to keep cleaning personnel out of critical areas. The only thing you'll get there anyway is dust; the programmers and system administrators can easily sweep the floors themselves once a week and it would give them some peace of mind.

  • Paolo G (unregistered) in reply to shortbaldman
    Mind you, if one was bouncing back and forth from COBOL to C it was a pain to remember it was a HYPHEN in COBOL variable names and an UNDERSCORE in C.

    Hey, that's nothing. You want to compare C++, where the assignment operator is = and the equality operator is ==, with Z, where they are the other way round. Sure, the latter is a specification language, but I still had to double-check which to use when I was a lecturer teaching both of these languages at university.

  • ThingGuy McGuyThing (unregistered) in reply to Soviut
    What's the deal with "cleaning staff breaking software"? It seems to be this reoccurring theme.

    See, this is why I don't bathe.

  • (cs) in reply to Andy L.

    Nobody would pay for your overtime. Or would you do it for free for your PHB?

  • (cs) in reply to Otis P Criblecoblis
    I thought I had purged all COBOL from my brain, but now with your mention of ENVIRONMENT DIVISION, FILE SECTION, and WORKING-STORAGE SECTION it's coming back.
    So did I... I only finished doing that stuff about 3 or 4 years ago.

    It was a bizarre environment. There were no techs and no creativity apart from the occasional contractor who came through. Training was kept to the bare minimum essential required to churn out the code.

    If you were seen handling a manual it meant you didn't know your job. I was often seen reading stuff that would make my job at least a little easier (like print layout macros I can't quite recall the name of. Instead of counting print rows and manually printing headers and footers you could set up rules that'd count/print for you). I was once called into the boss' office for a chat - he wondered how I was coping as I "seem to be referring to the books a lot".

    Of course, I couldn't apply anything I learned in production code as the maintenance programmer would probably be someone with no previous experience and 4-8 weeks training. There were strict standards.

    On the same floor there was a team of Java programmers (we worked with them on a project where data would come in from the Revenue Commissioners' web frontend for payments as XML. They were tasked with converting the XML to flat files so COBOL programs I wrote could import them to CICS with validation. This took a surprisingly long time. I wanted to implement an XML parser in COBOL... that's how bored I was).

    Anyhoo, the equipment we got wasn't too terrible - decent desktops for the time. The main problem was the monitors - 15" CRTs, [email protected] When my manager turned on her deskfan my monitor shimmied. The Java programmers claimed the complexity of their code meant they needed larger monitors (fit more code on screen) and so a bunch of 19" TFTs were ordered. Thing is, they didn't have access rights to change the desktop res so they just had an expanded 1024x768... blurry because it wasn't the native res of the TFT. They still lorded it over the lowly COBOL programmers with their new toys. :)

    Ah, government. All of these people were required to score above average in aptitude and intelligence testing :)

  • Roy H. (unregistered)

    I read this one in Computerworld at least 20 years ago. There was a column that collected such stories.

  • jaded (unregistered) in reply to shadowman
    This seems like just another variant of the most-likely-apocryphal story where the cleaning lady would unplug a server once a week to free up the outlet for the vacuum cleaner. I think that one was posted here a while back also.
    It's not apocryphal at all. In the 1980s we had the problem at a department store where the cleaning staff would unplug various cash registers to power their vacuum cleaners all around the sales floor.

    Because turnover among the cleaning staff was constant, training was never an effective answer. One month after warning them, some new cleaner was unplugging the same old registers.

    We finally solved the problem with a low-tech trick (and some money.) We paid for electricians to replace all our power outlets and the power cords on all the registers with bright yellow Hubbell twist-lock plugs. Once they realized their vacuum cleaner plugs would not fit in the register outlets, they stopped unplugging them.

  • Rob White (unregistered) in reply to Anon

    "So if she was using a punch card, that card was no longer there FOR them to run. It'd be like commenting out a random line of C code."

    Actually, chances are she was removing a random line of data, not code. If the code were getting shorter by one random line a week, it wouldn't have taken more than a couple of weeks to destroy the program.

    Besides, the program was already compiled somewhere, as compile-and-run for every job would have been unworkable. But even if it was compile and run every time, it would have been a different kind of error each time if the card was coming randomly from the code body.

    Usually, anyway, there is a card with a "data starts here" record on it and then the cumulative record. So what was happening was the manual computations were correct, and the results were off by one entry element. So if the record were for like $15.23, that one missing card would short by that much, If the next time it was $8.50 then the run would be off by a different number.

    A very hard error to find since the delta would be different every time.

  • (cs) in reply to Jana Vasseru
    Jana Vasseru:
    so i taped the empty sockets in the extension cable with bright yellow tape and written on it "Do not unplug anyting. Do not plug anything new into me! Especially NO vacuum cleaners, i hate vacuum cleaners."

    Well, you see you wrote half a book on a tiny duck tape. Who do you think can (and will) read all these small letters which must be hardly visible.

  • gravis (unregistered)

    The real WTF is that the cards containing important information were lying around in what must have looked like a waste paper bin.

    Training issue my foot.

  • Dan (unregistered)

    This reminds me of an old thinnet issue that caused our network to crash everyday about 10am. Turned out an enduser would kick off his shoes, lean back in his chair, and twddle with the coax connectos with his toes while he sipped his coffee everyday about 10am.

  • Dan (unregistered) in reply to James

    That's just about how it worked. A canned program would read however many accounting data cards there were. Good programmers added an end of deck card of some sort, but not everyone back then thought they needed one. A good comparison today would be parsing a CSV text file not knowing how many lines there are from run to run.

  • Jim (unregistered)

    Back in the day, I used to get into feuds with the phone company or electric company. I would get back at them by overpunching their remittance cards with a "/" in columns 1 and 2. "/" was the code back then for "end of data". I was certain that my revenge cost them much more than any overcharge they inflicted on me.

  • Dave (unregistered) in reply to Anon

    In the context of the problem, I suspect that was the data deck, since pulling a random code card would eventually make the program fail spectacularly. Loosing a random card from the data deck would only make the results of the run come out wrong.

  • irish (unregistered) in reply to Anon
    Can someone who knows how punch cards work explain to me why this is a problem? Did she use a card that was already punched, and thus threw off the computations the machine made based on the cards?

    Punch cards work like this: You write code, the code turns into cards that get punched, the computer runs off the punched cards. So if she was using a punch card, that card was no longer there FOR them to run. It'd be like commenting out a random line of C code.

    no, the story is missing something. Each line of code is on a card, but removing a line would cause it to compile incorrectly. Unless the card was a data set. Either way, it doesn't make much sense.

    I had an 500-line COBOL program once in a box of cards. Someone dropped the box and the cards scattered all over. THAT made me cry...

  • (cs) in reply to Ollie Jones
    Ollie Jones:
    I think the story about the cleaner using the card is an urban legend. But there are PLENTY of ways to lose a card that aren't simply mythical.

    I think you overestimate the technical reasoning ability of the non-technical person. Especially back in the 60's, when the majority of people had never used a computer.

  • radarbob (unregistered)

    Bob's Punch Card Stories, eh.

    Kolluge 4 years of IBM punch cards.

    The first run through the IBM 360 Model 70 computer was always a syntax check in essence. One learned to type well because of the time-suck of the whole process. Only 1 to 3 runs per day was typical on a normal day - if you could make time to get to the computer building! Near the end of every semester one was lucky to get one. However on Saturdays I killed many trees.

    Programs were always written twice, once on paper then on the punch card machine. No on the fly editing on a punch card machine!

    Sequence #s @ the end of each card was a PITA, so we very rarely did it. One prayed hard as he carried his card deck to the computer room.

    Every student had assigned card drawers. Every once in a while one of your card decks would go missing for a couple of days - another student had stolen it to copy. I saw it as a bit of a compliment.

    Ours was a small college and we had access to the computer room. I loved going in after hours and using the staff's punch card machines. Those had an input buffer so you could edit the line before punching.

    Old Dogs and New Tricks Punching was all in upper case letters and this is deeply imprinted on the COBOL programmer. You can't convince him that mixed case is easier to read. Years later people would freak out at times if you coded, now with actual on-screen editors, in lower case.

Leave a comment on “A Training Issue”

Log In or post as a guest

Replying to comment #:

« Return to Article