Parallel

A Personal History of Systems and Computers: Part 1

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:

Work for a computer manufacturer like IBM.

Work for a company large enough to lease a computer from IBM.

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:

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.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!