|
"Would you like to see the IBM room?"
November 18, 2008
URL:http://www.drdobbs.com/architecture-and-design/a-personal-history-of-systems-and-comput/212100542
Dan can be contacted at [email protected].
It was my first day at TRW in Harrisburg, Pennsylvania and I had just completed the usual new-employee paper work. Although Harrisburg was my home, TRW had recruited me from the Bell Telephone Company in Philadelphia where I learned computer programming and where I worked for almost a year as a programmer. Unlike Bell Tell, the personnel department at TRW consisted of just two people -- a manager and his secretary. It was the secretary who made sure that the proper forms were completed and who asked if I wanted to stop by the IBM room on the way to my new work location.
"Sure," I said. "I would really like to see that."
TRW occupied two buildings, the plant and the administrative office, on several blocks of Cameron Street. Since the plant employed over one thousand people and the administrative office had fewer than one hundred, the personnel office was located in the plant. The lady from personnel and I walked from the plant, through the parking lot, into the office, and to the IBM room.
The room we entered was 35-40 feet long and about 20-feet wide. In the far end of the room dozens of IBM card cabinets lined the walls. Moving past the card cabinets was the machine area with TRW's unit record equipment. I saw two 082 card sorters, a 085 collator, a 548 interpreter, and one 407 Accounting Machine. At the other end of the room was the key punch department with three 026 card punch machines and two 056 card verifiers. There were two desks, one for the machine room manager and the other for the key punch supervisor. I was introduced to the manager and the supervisor, and I waved at the three key punch operators as we left the IBM room. The lady from personnel led me up the stairs to the newly designated programming office. I met my boss, the Data Processing manager, and I was shown to my desk. I was home.
After I settled in, it occurred to me that the one missing piece of machinery in the IBM room was a computer. The computer, I was told, was on its way. The IBM model 20 was on order and would be shipped within a month or two. Before it was delivered, I would use a computer at the Harrisburg IBM office to run and test any programs that I might write. First, however, I had to learn what was going on at TRW.
At the Harrisburg works, truckloads of steel were unloaded at one end of the plant and manufactured engine parts came out the other end. In between, the steel was fabricated, milled, polished, and inspected. Dozens of machines were kept busy 24 hours a day making parts for jet engines. Attached to each machine was a plastic sleeve that held ten or so IBM cards. The cards were used to record the number of the part being fabricated, the specific process, the employee number of the workman, the amount of time consumed by the job, and any polish, grease or other material that was used in the process. The completed cards were placed in a pick-up tray that was off to one side of the machine. Several times each shift, someone went through the plant, collected the cards, and delivered them to the IBM room. The cards were then used to produce cost accounting reports, an elementary bill of material, and the union payroll checks.
Had I stayed with the telephone company, I would have become a technician. Programmers at Bell Tell were so far removed from their customers, whether they were the administrators who read reports or the telephone users who paid bills that the only real job satisfaction came from the elegance of the programming solution. Since there was no face-to-face contact with the person who used the product, a programmer had to be content with the knowledge that he had used fewer instructions or performed a faster sort than had been done before. But I went to work for a company where a programmer delivered reports directly to the accounting manager who might send both the report and the programmer back to the machine room to be run again. I was to learn that at TRW one sought the practical result and not the elegant solution.
TRW's emphasis on the practical was exemplified by the plant's second-in-command and Chief Financial Officer, an old Dutchman named Jerry Voots. The plant manager called him "Jerry"and the rest of us called him "Mr. Voots". Mr. Voots spoke with a Pennsylvania Dutch accent. He counted paper clips. He kept track of how many cards were punched each week by which operator. He was convinced that the company was going in the wrong direction by replacing the bulk of its unit record equipment with a new computer. Early on, I did little to make him change his mind.
Having toured the plant and seen how a part got out the door and then followed the cards back to the IBM room, I was ready to get started. A planning meeting was arranged by my boss with the IBM SE assigned to our project. The first item on the agenda was to schedule me to be trained in the Report Program Generator (RPG) language that was used with the model 20.
"Does the model 20 have an assembler?" I asked.
"Well, yes. The model 20's assembler is a sub-set of BAL but no one uses it," the SE told me. "Everyone uses RPG."
"Not me," I told him. "I'm an assembler programmer."
My boss and our SE looked at each other. They decided that I would be given one week to write one assembler program and get it working. If I couldn't do it, then I would go to Philadelphia to learn RPG. I agreed with the arrangement and I got to work. I chose to write a program that was to take cards that were sorted by machine number within employee number, sum the hours worked by each employee on each machine, and then punch summary cards and print a totals report.
I began with a flowchart. I studied which instructions were supported by the model 20 and which were not. I wrote my program. I played computer. I changed my program. I went to the local IBM office, dug out the model 20's assembler card deck, and assembled my program. I fixed the assembly errors. I punched a small batch of test cards and I tested my program. The report was readable although it needed some formatting changes. The cards were indecipherable. They looked like Swiss cheese. Some columns had four or five holes punched in them while other columns were blank. The printing at the top of the card was similarly unreadable. That's when I found out about the model 20's MFCM.
From a published report:
The 2560 MFCM ("Multi-Function Card Machine") reader/sorter/punch was for the Model 20 only. It had notorious reliability problems (earning humorous acronyms often involving "...Card Muncher").
Reliability wasn't the only problem that I experienced with the MFCM. I went back to my desk on Cameron Street and plowed through manuals, changed my punch commands, and tried again. I just couldn't make the MFCM punch cards that could be used.
In the midst of my frustration, I was summoned to see Mr. Voots and I was told to bring my program listing with me.
"Kom here!" Mr. Voots said as I approached his desk.
I sat in a chair and hung my head.
"Let me see." Mr. Voots pointed at my program. I gave him my most recent listing and watched as he picked it up and looked at it. He reviewed the program so intently that, for a moment, I thought that he might actually understand basic assembler language.
"Vy do you vant to use this crazy language?" He asked.
"Mr. Voots, I'm a programmer and this is the language that I know." I explained.
"So vat are people who use the other language?" He wanted to know.
I thought about it for a minute and then a minute more.
"I guess they're called programmers, too." I admitted.
"Go learn other language," he told me. He handed me my listing and sent me on my way.
Later I found out that I never had a chance with my assembler program. The MFCM had such timing issues that in order to read a card from the read hopper, register a blank card under the punch dies, and select a stacker, the program would have to build in delays at every step. Only the IBM engineers had been able to make it work correctly and they had transferred their knowledge to the access routines used by RPG. Nonetheless, I know that I had crossed a threshold. Indeed, RPG led to COBOL and it was only after a brief stint writing Autocoder again that I got back to being an assembler programmer.
I did go to Philadelphia and I did learn RPG. I wasn't an enthusiastic RPG programmer, however, until my return. My boss asked me to try rewriting my old assembler program with the new language. It took less than an hour. It worked perfectly on the second run.
I learned that at TRW one sought the practical result and not the elegant solution.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.