Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Home Writing and Testing the Calling Routine

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.

1 | 2 Writing and Testing the Calling Routine Next Page

RELATED ARTICLES ZHMICRO Releases C++ IDE Integrating jQuery Client-Side Data Templates with WCF Encrypting the Internet Three 'Best' Persistent Model Patterns Announced Milepost GCC Now Available		TOP 5 ARTICLES No Top Articles.