- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
Not to mention the JCL ... <G>
Admin
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.
Admin
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
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
See, this is why I don't bathe.
Admin
Nobody would pay for your overtime. Or would you do it for free for your PHB?
Admin
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, 1024x768@60Hz. 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 :)
Admin
I read this one in Computerworld at least 20 years ago. There was a column that collected such stories.
Admin
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.
Admin
"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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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...
Admin
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.
Admin
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.
Admin
this reminds me of as similar story: someone checking the Tape backups noticed that ALL of the tapes on the bottom shelf were blank or corrupted! the cause was eventually determined to be... the electric motor on a vacuum cleaner or a floor waxer!