|
So you want to be a -- what? -- programmer?
August 04, 2008
URL:http://drdobbs.com/parallel/a-personal-history-of-systems-and-comput/209902652
Dan can be contacted at [email protected].
I became a computer programmer during the 1960s and it happened in a hotel room in Philadelphia, Pennsylvania. At the start of the '60s, no one really knew what a "programmer" was or how to become one. At first, programmers were the engineers who understood the circuits and processors, but it became obvious that if a company wanted to sell computers, the buyer would need a way to program them. By the mid '60s, a rigor was being established and programmers were being produced with some frequency.
In January 1966, I went to work for the Bell Telephone Company of Pennsylvania and learned to program the IBM 1401. I was 18-years old, had graduated from high school the previous June, and I applied for a job with Bell Tell because I wanted to be a telephone repairman. Actually, I wanted to have my own repair truck. Whenever I went to one of the local diners for breakfast, the parking lot would have five or six telephone company trucks scattered about while the repairmen were inside seated around a big table having a good time. What a job! You go to work, get in your truck, and go to the diner for breakfast, all on company time.
One of the pre-employment tests I was given was a programming aptitude test. The test must have ratted me out because after about two weeks on the job I got a notice to report to the personnel department where I was introduced to a recruiter who had come all the way from Philadelphia to Harrisburg (about 100 miles by turnpike) to offer me a job as a "computer programmer." That I had never seen a computer was not important. No one had seen a computer. The Bell Telephone company would train me, move me, and put me to work. The clincher was the 10 percent raise that would take my salary to $82.50 per week. Done deal. The next Monday morning I started to learn about computer programming.
The company trained programmers in a room at the Ben Franklin Hotel in Philadelphia. That first Monday morning, however, our instructor led his 15 students from the classroom to the telephone company's data center on Arch Street. There we saw computers. The 1401, used by the telephone company to process telephone bills, was a slave to the IBM 7070. At the data center, the 7070 was center stage in front of the picture window into the machine room. The 1401 was placed to the side and behind its bigger brother. Although both were second-generation mainframe computers with transistor circuits, the 7000 series machines were bigger and faster. They were so fast that neither card-processing equipment nor printers were attached to it, only tape drives. In second-generation computers, there was one program resident in memory at a time. No software was delivered with the mainframe. There were no operating systems, compilers, or utilities in general use. When the resident program issued an instruction to read a card, the computer read a card. Then it waited. All of those machine cycles that passed while the card fed into the hopper of the card reader, ran under the read head, and transmitted data to memory, were unused. Since tapes held bigger records and transmitted data to the processor quickly, they wasted fewer machine cycles. Of course, there was one small problem with removing the card readers and printers from the 7070. Telephone bills were printed, mailed, and received on 80-column cards. It was those darn cards that created the need for the 1401.
IBM called it the "1401 Computer Processing System." It was a system because there were three original components:
Tape drives were added later. IBM introduced the 1401 in 1959 and by the end of 1961 it was installed in over 2000 locations. In 1961, there were fewer than 10,000 mainframe computers installed anywhere and the 1401 was becoming the solid-state generation's star performer. It was relatively cheap, with monthly leases starting at $2,500, and it was a workhorse. Any company that was already using equipment to process 80-column cards could fit the 1401 into its machine room. The 1401 was equipped with 4,000 (not 4096), 8,000, 12,000, or 16,000 8-bit characters of core memory. The first 6 of a memory position's 8 bits were used to encode a character in Binary Coded Decimal (BCD). The two remaining bits were for parity check and a word mark. The 1401 was a true child of the '60s. By 1971, IBM discontinued the line.
As we walked back to our classroom that Monday morning, I didn't realize how fortunate I was. In 1966, there were only two ways to learn how to be a computer programmer:
Since we were in the latter group, we were taught Autocoder by a Bell Tell employee.
We learned that the 1401 was a variable-length word machine. Instructions could be one position or longer. The address operands, when present, were three positions. The end of an instruction was detected by a word mark under the next instruction's operation code. In machine code, the numeric character 1 was both the op code and complete instruction to Read a Card. That was it. Nothing else was needed except a word mark (that eighth bit available at each memory location, turned on when the content of that location was an op code). Once the card was read, where in memory are the 80-columns of data placed, you wonder? In positions 1 through 80, of course. The 1401 mapped the first 333 positions of memory for card input (1-80), card output (101-180), and a print line (201-332). The 333rd position of memory could be used for printer channel control. If you are scheming how to use those leftover positions from 81-100 and 181-200, you are ahead of the game.
After a day or two, we were given our first pad of Autocoder coding forms. Think of a spreadsheet, printed landscape, with four columns and grid lines. The columns, from left to right, were for a sequence number, a label, the operation code, and the a and b address operands. The Autocoder symbolic operation code to Read a Card was R. On a single line of the coding form, the programmer coded an R. The instruction could have a tag if it was the target of a branch and, at the beginning of the line, it usually had a sequence number. We coded the sequence number by tens so that we could add instructions when needed. Since data entered the 1401 by 80-column cards, the sequence number provided for the time when the programmer dropped the deck of cards on which his program was punched. With sequence numbers, the card sorter could put the program back in order quickly. Without sequence numbers, the programmer had a long day ahead of him.
Here is a simple but useful Autocoder program to print the data punched in a deck of cards:
01010 Card EQU 0 01020 Print EQU 200 01030 CS Print+132 01040 CS 01050 Start R 01060 SW 1 01070 MCW Card+80,Print+80 01080 W 01090 CW 1 01100 CS Print+132 01110 CS 01120 BEOF End 01130 B Start
The R, W (Print) and B (Branch) instructions are straight-forward, as are the two equates for Card and Print at the beginning of the program. The SW instruction at sequence number 01060 sets a word mark in memory position 1 and the MCW instruction that follows moves characters starting at memory position 80 to memory 280, one-by-one, right-to-left, until it encounters a work mark. Once the data is moved to the mapped print area, it's written to the printer. The clean up instructions at sequence numbers 01100 through 01110, like the housekeeping instructions at 01030 and 01040 clear storage in the print area. The last CS instruction takes advantage of the fact that the address registers remained as they were at the end of the previous instruction. The CW, of course, clears the word mark.
Once we started writing programs like these as classroom exercises, we had to get our code keypunched into cards. In some installations, programmers punched their own programs while in others, they did not. In my experience, whether you punched your own program was your choice. I usually sent my first draft to the keypunch department, then punched my own changes. The keypunch operators were accurate and they would punch the sequence numbers. I knew that I never would.
Since we didn't have a keypunch machine installed at the Ben Franklin Hotel, we didn't punch our own programs. Instead, we put our coding forms that were going to the keypunch department in a basket on our instructor's desk. There was a second basket for our card decks that were going to be assembled. An Autocoder program became an object deck with machine instructions after a two-pass assembly. The first pass produced a deck of cards or a printed listing. If your program had invalid syntax, there was no second pass -- just a printout with your errors. If the first pass was clean, the cards that were punched were inserted into the object deck of the second pass. The whole thing was then loaded into the card reader. The second pass produced an assembly listing and an executable object deck.
If you sent your program to be punched on Tuesday, you could get your first assembly on Wednesday. You cleaned up your syntax errors and got a second assembly on Thursday. By Friday, you might be looking at a full assembly listing. The big question was whether your test would be successful. If not, you sent your corrections to be punched on Tuesday ....
After a week of instruction, if I had been asked to define a dozen Autocoder commands, I could have written them properly and defined them accurately. If I had been asked to use those same commands to write a program to print the cards, I would have been lost. To help us visualize the steps required to print those cards, the class was introduced to flowcharting and we were issued our first flowcharting template. For the next 10 years, when I started a new job, I was given the essentials of the trade -- an IBM Assembler Language green card that had all of the instructions that a programmer needed and a flowchart template. Although in 1966 we didn't think in terms of modeling languages, flowcharting remains, to me, the best way to model a sequential process.
In class, we began by identifying each step taken by a student as he moved from his work table to the instructor's desk and then returned. We wrote the steps on a piece of paper. We discovered what to do when the student made decisions ("Am I there?" "Should I turn to the right or left?") and we learned how to bring the student back to his starting location. We used our template to convert our written instructions to a flowchart. We were then given an 80-column card and asked to diagram the process needed to punch and print it. Eureka! I did it. It made sense. I had become a junior programmer in training.
During our third week of instruction, I was selected, along with a few classmates, to learn the IBM 360 Basic Assembler Language. The telephone company had purchased six 360 Model 30 mainframes and they had accepted delivery of the first two of them. Then Bell Tell looked around and discovered that they needed IBM 360 programmers. So, the Monday of my fourth week of instruction, I reported to the IBM Education Center at Suburban Station to begin my training in third-generation computers. The story of learning BAL, as it was called, and how it brought me back to Harrisburg will be covered in the next installment.
It would take more than three years for me to return to systems written in Autocoder. By then, IBM had released a 1401 emulator for the 360 that ran flawlessly. Although I worked with Autocoder programs well into the 1980s, they were always run on 360 Model 30 or Model 40 mainframes. As fate would have it, the only time that I ever saw a 1401 computer in operation was that first day at the data center on Arch Street.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.