There are no prizes for working out the identities of those involved in the following incidents but there is no doubt that they will recognise themselves.

She was Australian and an expert programmer, but this time she was stumped. She had done all the right things, had carefully debugged the program and established its correctness with a minutely prepared deck of test cards. It had gone into production and then after several production runs the program bombed.

The computer had variable length instructions and each operation code had to be indicated by a bit called a word-mark and now the machine had hung up having branched to an instruction without a word-mark. Something was wrong. After all the program had worked before! The instruction was in the correct place and had performed its function many times. All was well up to the point of bombing. The machine must have dropped a bit and that was the cause of the bug. But the theory did not work out. The error repeated itself exactly. So she followed the standard procedure on that machine. ‘Open the control panel, turn the dump knob, press the button’ and out would come a memory dump on the printer. Everything was fine in the program except for one thing. All the word-marks up to the faulty instruction had disappeared! She was very quiet for a few days (especially for an Australian), but when she solved it, we certainly heard about it.

The computer had special hardware for editing numeric data for printing commas and periods etc. As part of the edit operation a two-way scan took place with a word-mark being set in the print area, and then cleared at the completion of the second scan. The incorrect use of this instruction, together with certain properties of the edited numeric field, resulted in the second scan extending up memory from the print area to remove a word-mark from an instruction. Gradually as these unusual conditions occurred, the program had its word-marks eaten away until an instruction in use was reached. The program was gradually destroying itself internally.

After that she invented a group of three self-consistent instructions that could be dropped into anyone’s program, with the result that that program would eat itself away to bomb with a completely cleared memory behind it. Fiendish!

* * *

The processing of wool sale accounts in New Zealand, while not the first computer bureau application here, was the first of any size. It revolutionized the industry and resulted in changes to the way the sales were run.

It was my baby and it certainly gave me plenty of problems. I had to find ways of printing totals before the last detail line had been reached and put half the detail lines on the next page if they did not all fit on to the first one. For one report I had to internally sort the wool types for each statement. I thought I had worked out a good technique for speeding up the sorting process only to learn much later at the university that there are significantly better methods. Seeing that the occasional statement took several minutes it would have been nice to know at the time. It was a night and day project. Hands on testing at night and debugging and corrections by day. The strain really came when a colleague bombed out on his program and I had to do that one as well. He just failed to make the transition from punched cards to computer. He went on to sell vacuum cleaners. August 1st 1963 and it was the first wool sale of the season — held in Wanganui. Ready or not, we had to process it. The sale prices were phoned down and punched into cards. At six p.m. we moved into a client’s office to buy hack the machine time we needed.

At midnight, with part of the job done, we packed up again and moved across town to another client’s office to get the use of their extra memory sized machine, all of 12,000 characters! This was needed for the sorts of wool for the growers’ accounts. It must have been about three in the morning when we struck problems. My manager had been roped in to write some minor summary report programs but a careful check of his output showed they were faulty. I think that too much RPG had damaged his technique.

Being a manager he was, of course, at home in bed so I had to manage this myself. By persevering I found that I could effectively produce the summary sheets by running in each separate control group by hand.

Back with the customer, the growers’ accounts were individually checked line by line before they went out. However, it did not take the usual two weeks for the farmers to find out what their proceeds were.

The bugs fortunately did not appear until later. This was the job that made me into a computer professional. After all, I had passed the ultimate qualifying test: I had seen the dawn rise over the computer system while getting the job done.

* * *

For better or for worse she had promised to cherish him — but did this really mean she had to drive from Wellington to Palmerston North in the middle of the night to pick up a programmer, a guest at a wedding there? Paul knew what he had fed into the program. He was the only one who could help to sort out the problem. ‘Put an eiderdown and a pillow in the back of the car’, her husband said over the telephone at a quarter to one in the morning, ‘so that he can sleep on the way — and give him breakfast; then have him here, fresh, at eight o’clock.’

She did it. She still doesn’t know why she did it. All those dark miles. She could have said, ‘Why don’t you go yourself?’ but she didn’t. Computer wives and computer husbands, like their partners, have to be rather special people.