Writing and Testing the Calling Routine
The writing of that calling routine and the testing of my queue became an exercise of discovery. When I first tested the two together, one routine or the other would have an error that caused a core dump. When I read the dump, I could find the problem and also see how the queue table was being constructed. One day, however, the only thing that I got back from my test was a piece of green-bar computer paper that had an end-of-job message. The routine had run without error. After a moment of exhilaration, I realized that I didn't know if the queue had filled correctly. All I knew was that it hadn't blown up.
I pulled out my desk-checking test cases. I decided where to place constants that would cause core dumps in my queuing routine. Before each test, I changed the calling routine to send different messages to the queue and I determined what I wanted to see in the core dump. Each morning I got my test results. In the end, the tests were completed and I took my core dumps to my senior programmer. He looked them over and agreed that the queuing routine was tested and complete. He told me that the queue would be put on the shelf and when the control program was finished, the queue would be ready to go. For all I know, the routine is still on that shelf because shortly after it was completed, I decided to move back to my home in Harrisburg.
During the late '60s and throughout the '70s, the IBM salesman was the key to placing programmers in computer installations. The process was highly unofficial but no less effective for being conducted in secret. Once I made it known that I wanted to relocate, the word must have been passed and, before long, I got a phone call. A major corporation, TRW, with a plant and administrative office in Harrisburg, was looking for a programmer. TRW's main office in Cleveland had purchased an IBM 360 model 40 and they had decided to place 360 model 20s in their branch locations. The caller wanted to know if I would be interested in moving back to Harrisburg to help them convert their existing unit record systems to the soon-to-be installed model 20. By the way, the caller told me, the job would pay $110 each week and allow unlimited overtime. I never asked and the caller never told me how TRW had gotten my name. I would be rich. I took the job.
Soon after I started with TRW, I went back to the IBM Education Center in Philadelphia for a three-day class on the Report Program Generator (RPG) language. While there, I had a cup of coffee with an IBM Systems Engineer that I had met while I worked for the telephone company. He said that Jack had asked him to find out how I liked my new job. Jack, of course, was an IBM salesman. Nothing else needed to be said. We both knew that, like the godfather, I owed IBM a favor that might never be needed but which IBM would expect to be paid if required.
In the next installment of this series, I'll describe IBM's unit record machines and my experiences with them and the 360 model 20. Before I leave Philadelphia and the telephone company, however, I need to comment on the CRBO project in which I played a small part. It was one of the most ambitious technology undertakings of its time. It was an effort worthy of the institution that gave us the Bell Labs, information theory, and the UNIX operating system. They just don't make 'em like that any more.
- A Personal History of Systems and Computers: Part 1
- A Personal History of Systems and Computers: Part 2
- A Personal History of Systems and Computers: Part 3
- A Personal History of Systems and Computers: Part 4
- A Personal History of Systems and Computers: Part 5
- A Personal History of Systems and Computers: Part 6
- A Personal History of Systems and Computers: Part 7
- A Personal History of Systems and Computers: Part 8
- A Personal History of Systems and Computers: Part 9