It is not always necessary to fix an error.
When I was 19 I worked for a very large enterprise (in the fields of electronics). I was an operator for the mainframe. I sought this type of job deliberately because I wanted to be near a computer.
There was a special program that had to be run each month. It was called OP and dealt with reminders and demand notices. Normally, it ran for eight hours and it was a nice program. You had to insert about one foot of punch cards. The program used to run without interaction. Every half an hour you had to go to the tape room and change tapes.
(Actually, this happened during a sort. The programmers who had programmed the task had done so in Munich where there were six tape units. In Vienna there were only four tape units. It was a kind of a "scaling-down"-bug of the sort-and-merge-program. I got this knowledge many years later.)
In order to continue one had to toggle in some register values on the console. The numbers were displayed with 4 lamps, displaying the value in excess-3-code.
Then one had to toggle in a restart address and with the pressing of the RUN-key the program continued to its end marvelously. I remember that I was stunned when I watched this procedure the first few times. It was not written down anywhere. The information was passed from operator to operator.
I did not think I would ever be able to manage the entries. I was much to frightened that I could possibly do anything wrong. As you can imagine, it did not turn out a real problem later on.
At that time I did not understand why this bug wasn't fixed. I considered it a risk, when human beings had to interfere with batch programming. (Everything was batch in those days.) Actually, there was plenty of room for embezzlements or fraud.
Today, I understand. I try to convince people that errors in software are inevitable, but I also teach the Juran-curve to them. I could easily justify today why the error was not fixed in those days.
Keine Kommentare:
Kommentar veröffentlichen