|
|
| Non-WTF Job: Software Developer at Rustici Software (Franklin, Tennessee) |
|
|
|
| Non-WTF Job: Software Developer at Rustici Software (Franklin, Tennessee) |
| « 2.7: The Numbers | Yes, the Table is Still There » |
"Oh, hey, that's weird." One of Initrode Global Insurance's accountants spotted an error on a printout of the previous day's sales report during her daily review. She dug through her records and tried to isolate the small, but still troubling, discrepancy between the totals. After reading through several previous days' reports and asking around, she couldn't find anything that could've caused the error. She circled the incorrect number, wrote the correct total, and took it to her boss's office.
"Hey, that's weird," her boss said. After checking and rechecking, it was clear — this was a problem with the report generated by the big iron (an IBM mainframe). After making the rounds in accounting and then through IT, it was ultimately put on a low level programmer's desk for him to investigate.
It was the mid 1960s, so naturally all of Initrode's applications were built in COBOL. The archaic punchcard system was in the process of being phased out in favor of a newer magnetic tape reel technology. For two years the system had performed well, and aside from the usual kinks when the system was first rolled out, there hadn't been any issues like this in months.
The programmer did all he could to find the problem, but wasn't able to locate it. After five days, still no resolution, but at least the issue hadn't shown up again. Everyone reasoned that it was a fluke, maybe a card with a hanging chad or a one-time read error.
Sadly, a day or two later (exactly one week week after the issue had originally appeared), the same thing happened. Another negligible difference between accounting's paper reports and the computer's output.
The developer went to the card bin to verify that none of the cards were folded, spindled, or mutilated — nothing. He checked the numbering on the cards, and again, nothing. Another programmer was assigned to investigate, and between the two of them, they still couldn't figure it out. There was no apparent relationship to the job's parameters and the amount of the discrepancies. None of the equipment, code, or staff had changed, no accounting procedures were different, but this problem would still appear every week.
After a year, there was still no fix. Ashamed, the developer vowed to work late the next Thursday night, promising himself he wouldn't leave the office until it was fixed. He pored over every ENVIRONMENT DIVISION, every FILE SECTION, every WORKING-STORAGE SECTION. He checked every variable to make sure that the decimals were in the right place, that no precision was lost in any output anywhere, and that all data files were closed properly. At his wit's end and cursing the 1960s for not having invented Red Bull yet, he leaned back in his chair in frustration. At that moment, a member of the cleaning crew came walking through the door. She politely said "hi" and asked if her cleaning would disturb him. Happy to have another human being in the room, the young developer invited her in.
"No, it's fine, go right ahead," he said weakly. She thanked him and began her cleaning. The young developer got back to work and was pretty sure he was close to the bug when he heard a startling *crack*.
"Sorry," the cleaning lady said, picking up the hand broom she'd dropped. The developer's attention turned to her while she swept up some dirt into a small pile. Nonchalantly, she reached into the punch card bin and swept the dirt onto one of the cards, picked it up and carried it to the trash, and threw away the card with the dirt.
The developer may have wept then.
(thanks to Robert R. for the story)
Re: A Training Issue
2008-07-15 10:26
•
by
Anon
(unregistered)
|
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. |
|
Not that switching to magnetic tape would help. We lost months of data because some janitor was told to polish the floors--including the tape storage room. The floor polisher motor degaussed all the tapes in the bottom two shelves of all the racks, and the third shelf up was only saved by an act of Reed-Solomon...
|
Re: A Training Issue
2008-07-15 10:34
•
by
Escalator
(unregistered)
|
|
It does sound like that, but these things do happen.
A while back, I was sysadmin for a small-ish call centre in the southwest UK. Amongst our various servers was a small unit that had originally been a desktop, but had had Linux installed on it and was temporarily acting as mail server for the company. Now, whilst we had UPS for our "mission critical" machines - PDC, fileserver, db server, and the server that ran the call centre package we used - the little Linux mailserver was just plugged into the wall like any other desktop. It ran fine for about a week following deployment. Then, the first Monday morning following installation, I arrived in work to find the early-rising MD running around like a headless chicken. "Email is broken!" she wailed. "Fix it now!". First port of call, obviously, was the mail server, which I found be sitting awaiting approval to run a full disk check. "Odd", I thought, and let it run. An hour or so later, mail was back up and all the stuff that had been sent over the weekend arrived in people's mailboxes. All was fine for the rest of the week. The following Monday, I arrived in work to find that "email is broken again! Fix it now!". Of course, I went to look at the mailserver. This time I found that it was unplugged. Consequently, I asked about the areas that the weekend cleaners covered, and was told that yes, the server room was an area that they were supposed to clean, and yes, they had a key. I affixed a small Post-It note to the plug that read "DO NOT UNPLUG!", and the mailserver served us reliably and faithfully for another six months until management made good on their threat and bought a new server and a copy of Exchange. But that's a whole other story... |
Re: A Training Issue
2008-07-15 11:25
•
by
Ollie Jones
(unregistered)
|
|
Gosh, I am an old-timer. The same kind of thing happened to me....
Here's how this kind of thing worked with the IBM 026 and 029 keypunch machines. The programmers punched their COBOL programs onto cards, or put them onto coding forms and had them punched by keypunch operators. Whether done by programmer or by operator is important, because the operator usually had a "drum card" (a simple keypunch-machine program coded onto a card) that made the keypunch machine put a serial number into columns 73-80. Most programmers didn't do this, because it was a pain to correct errors. Then, we ran the source deck through the compiler and link-editor, and the binary code was punched by a monster punch-card output device into a shorter deck of cards. (You could have your program wake up the night operator by punching all the holes out of a card.) We put our binary code on pink cards where I worked. Now, in properly run shops, the source code was put into a source-code control system, that is, a punch-card file drawer with a lock on it. And the binary code was kept handy to do the data runs. The data was itself on punch cards. Each little transaction was on a card by itself. Remember, these computers didn't have any files, any disks, anything. The data was on the cards. A lot of the time, the next day's run was done by punching the day's information, slapping the newly punched cards after the existing ones, putting the pink cards at the front, slapping the whole mess in the card reader, hitting the big green button on the card reader, and jumping back. These card readers were monster machines, and very capable of grinding up three or four cards if they jammed. That was the most common reason for cards getting lost (sometimes operators were careful to try to make a replacement card, and sometimes not so much.) So, questions: Did the data cards have serial numbers? Well, yes, if the days' data punching discipline got them put on there. The drum card could do it. But the punch operators might or might not have been instructed to do that. Did the program know how many cards it was supposed to read? Well, yes, if it was programmed that way, and somebody manually counted the cards in the input deck, and punched another card with the card count on it. So, it's easy to see that a lost card could cause a discrepancy. If there's a WTF, it is that well-run systems in those days (and these) were very careful about batch totals, etc. 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. Man, was I happy when I got my hands on a "dumb terminal" and the early vi editor! |
|
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.
DATA DIVISION !!!!!!!! PROCEDURE DIVISION !!!!!!!!! PERFORM 00190-BEGIN-INITIALIZATION THRU 00190-END-INITIALIZATION !!!!!!!! MOVE CORRESPONDING 050-INPUT-RECORD TO 050-OUTPUT-RECORD !!!!!! AAAAAAAAAAAAUGH!!!!!!!!!!!!!!!!!!!!!!! |
| « 2.7: The Numbers | Yes, the Table is Still There » |
JaySee:
