|
Now what exactly is a queue?
October 01, 2008
URL:http://www.drdobbs.com/database/a-personal-history-of-systems-and-comput/210605028
Dan can be contacted at [email protected]/
For five weeks during January and February of 1966, instructors from the Bell Telephone Company of Pennsylvania and experts from IBM taught me computer programming with IBM 1401 Autocoder and IBM 360 Basic Assembler Language (BAL). (I talked about my learning experiences in Part 1 and Part 2 of this series.) By the end of February, I was ready to be assigned to my permanent work group with Bell Tell at One JFK Boulevard in Center City Philadelphia. I joined a five-person team that was part of the telephone company's CRBO (Customer Records Billing Office) project. The purpose of CRBO was to put IBM 2260 cathode ray tube terminals in the Conshohocken billing office and provide the service representatives with on-line access to customer files. The programming was being done in 360 BAL and I was confident of my programming ability. I knew all of the instructions, I had been given my first green reference card, I was ready to go -- and I was in for more than one surprise.
Our team was writing subroutines and handlers for many of the CRBO project's on-line processes and I was assigned to write the queuing routine. I was given an engineering drawing of the queuing table and a narrative of the procedure to be programmed. Now, I wondered, what exactly was a queue?
I was a junior programmer who was assigned to a senior programmer. Our programming team reported to a programming manager who was nicknamed "Trap." I don't remember why he had that nickname and I don't remember my senior programmer's name. I do remember sitting at Trap's desk as he and my boss explained the need and purpose of queues. The telephone company had determined that during peak periods the customer service representatives would be sending more on-line requests to the computer than it could handle. During lower activity levels, the 360 mainframe could receive, process, and respond to requests as they happened. During peak loads, requests would be received before the mainframe was finished with a transaction received earlier. At such times, the on-line control program would need a place to store the customer service request until the mainframe was available. The place that the request was stored was the queue and I was to build it. Transporting the customer service request back-and-forth from the control program to the queue was the queuing routine and I was to write it. With that, they sent me back to my desk to begin my first programming project.
It seemed that the control program didn't actually send the request message to my routine. The control program passed me information about the message. My queuing routine received a small record that included the address of where the request message was being stored and the time that the message was received. I was to place this small record into the queue table in order by the time of day in which the message was accepted by the mainframe. When the control program was once again ready to process transactions, my queuing routine selected the proper message information record and sent it back. If the table was full, I sent the control program an error code.
I struggled with the instructions and agonized over the best way to handle this or that condition. Finally, I finished the programming and corrected the assembly errors. With my program listing in hand, I went to see my senior programmer to find out how I could test the queuing routine. My senior programmer looked at the listing and then looked at me. He asked me if I had desk-checked my routine. Silence. Desk-checking was something new to me.
My senior programmer took a blank piece of paper and drew a table with about a dozen rows and three or four columns. Each row, he explained, was for a different test case. Together we completed the first row. In that first test case, the control program sent the first message information record and my routine placed it in the queue. Then, we thought of several other tests cases. My senior programmer sent me back to my desk to dream up all of the possible conditions that I could. After I filled the first column of the table with test cases, I played computer and ran each case through my routine. I followed branches. I built queues. I ran out of space, and I found several errors that needed correcting. My queuing routine was desk-checked. Now I was ready for the real thing. I wanted to interface with the control program.
With a smile on my face, I reported to my senior programmer that the queue was ready to be tested with the control program.
"Sit down for a minute," he said. I pulled a side chair to his desk and sat down. He didn't look at the program listing.
"The control program isn't ready just yet," he said. "You'll need to figure out some other way to test the queue."
"When will the control program be finished?" I asked.
"Six months," he said. "Maybe more. You need to write another routine to call the queue and pass it the information record." I stood up, moved the side chair back against the wall, and returned to my desk.
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.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.