Dan can be contacted at Dwohlbruck@aol.
As the Data Center Director for Financial Computer Services (a wholly-owned subsidiary of Gulf Life Holding Company in Jacksonville, Florida), I had the luxury of my own office. Although small, the office had three windows -- one looked out on the St. Johns River, one looked into the data center of which my office was a part, and the third window looked at the sliding door to the raised-floor computer room. In other words, I could see who was coming, I knew what the data center operators were doing, and I could look at where I usually wanted to be.
After I had spent the first few months of 1976 running FCS' data center, I had a pretty good idea that the best way to gauge the result of the previous night's operations was to count the number of phone calls that I received. I'm a morning person and I tried to get to work before the night shift left the building. I soon learned that they rarely gave me reliable information.
"How did it go last night?" I would ask the lead night shift operator.
"Great, boss," was the invariable reply.
A "great" night could mean that by 9:00 am I had one half-dozen phone calls reporting problems or, on occasion, it could mean that there were no phone calls at all. No reported trouble calls was the best thing that could happen to the data center director. No calls, in turn, meant a long lunch and an early departure for home.
As a systems person in search of answers and long lunches, I decided that I should learn and document what it was that the data center operators did all night. It was, after all, a pretty easy job, I reasoned. In my years as a programmer, I had mounted tapes, punched cards, put paper in the printers, and run my share of test programs. And there was, at that time, a prejudice that everyone in the data processing community held but which no one ever voiced aloud: programmers were smarter than operators.
I started my data center documentation project as I would have started a similar project in any other department. I gathered all of the available reports, schedules, guides, and procedures and placed them on my desk. The only papers that I could find were copies of the shift leader's daily report. That was it. Surely, I thought, there had to be more. So, like the good manager that I thought that I had better become, I decided to spend a few days on the night shift.
Later that day I waited until the night shift operators came to work and I invited the shift leader to come into my office.
"Jack," I announced, "next week I'd like to observe how you guys run the daily cycle."
Perhaps it was my imagination but I thought that I could see the color drain from his face.
"We didn't do anything wrong it wasn't our fault DON'T PICK ON US!" he stammered and yelled.
"Jack," I assured him, "I just want to find out how things work, not find anyone's faults. Anyway, next Tuesday and Wednesday, I'll be here with you. And I'll buy the pizza."
John wasn't mollified but he accepted my offer.
I was to discover that, in fact, the nightly processing cycle started early in the afternoon in the tape library. Like other jobs that we've seen, the tape librarian's functions have either become unnecessary due to the increasing use of disk storage or they've been automated by mechanized tape systems. At that time, in 1976, the tape library was where everything started and ended and the librarian was an integral part of any procedure.
By the end of the 1960s, magnetic tape had overtaken cards as the primary medium for storing data. Cards were heavy and cumbersome to transport, cards were stored in drawers where they could warp, cards were dusty, and cards were almost impossible to secure. Magnetic tapes were comparatively light, they were stored in racks and they created no dust, and when put in a vault like the one we used at FCS, magnetic tapes were easy to secure. Although we would punch cards for another 10 years, all of the company's operational data was stored on tapes. On this basis, because everything was on magnetic tape, someone had to organize the newly created master files after each processing cycle and then retrieve them in preparation for next cycle.
You might wonder how the tape librarian organized the company's tapes. The FCS tape vault (a real vault -- fireproof, waterproof, and made of steel) had racks around the walls and down the center of the room. The racks held five rows of tapes and each slot was numbered. Some racks were reserved for static data like month-end master files and backups that were kept on-site for a few weeks and then sent off-site. The other racks held data files or work tapes. A work tape was one whose data was no longer needed and could, therefore, be written over. At the end of each processing cycle, the librarian brought order to the confusion of new master files and newly obsolete information.
You might wonder how the tape librarian knew which reel of tape was a master file and which reel of tape was not. A great question! First, it's important to note that the tapes themselves, when not mounted on the tape drives in the computer room, were kept in clear, plastic canisters. The first time that I looked around the tape vault I noticed that more than a few of the canisters had labels affixed to them. There was a time when the computer operator would write the name of the file on a label and then place the label on the tape. It probably took less than a week for that procedure to lead to catastrophe. At FCS, the librarian had a pre-printed inventory with the names of the tape data files that were input and output from each night's cycle. For input files, the inventory showed the serial number of the tape to be used. As new files were created, the operator recorded the tape's number on the inventory.
IMPORTANT: Operators never, ever went into the tape library. The librarian had two carts, on wheels, with two rows of magnetic tapes. The librarian loaded one cart with data files and the second cart was left empty. During the day, the librarian placed work tapes on stationary racks in the computer room. As the librarian was leaving, he closed the door to the tape vault, he rolled the carts into the computer room and placed the tape inventory on top, and he was long gone before the night shift arrived. The operators on the night shift would fill the empty cart with work tapes that had been written over with new data. The final act in this drama happened at the end of the night shift. The operators rolled the carts out of the computer room and tried to find new ways to wedge them in front of the door to the tape library. They, in turn, were gone well before the librarian arrived in the morning.
And yet, somehow this process normally worked.
You might wonder how many magnetic tape files were created, inventoried, and filed from each nightly processing cycle. The cycle progressed, step-by-step, like this: First, all of the cards that were punched during the day were read and loaded onto tape. The tape was sorted by policy number and the sorted file was kept. The sorted transactions were validated and the tape with valid transactions was saved. Sorted and validated transactions were matched to the policy master file and that tape was saved. In all, the interim results of more than two dozen steps, not to mention the actual updated master files, were cataloged and saved each night. The interim results were saved so that the cycle could be restarted at any point necessary in the case that an error was found.
Each processing step in the nightly cycle produced printed paper as well as magnetic tapes. The paper went out the back door of the computer room and the tapes went out the front door.
And yet, I found after I completed my study and review, this process usually worked.
Toward the end of 1976, my boss asked me to come into his office. He invited me to sit down. He told me that he was sending me to Atlanta for a week to attend an IBM class. He paused. He told me that I was being sent to Atlanta to learn OS JCL -- called the worst programming language ever invented -- and that we were going to convert from DOS to OS.
In the 11th installment of this history, I'll tell you all about the job control language for IBM's operating system.
- A Personal History of Systems and Computers: Part 1
- A Personal History of Systems and Computers: Part 2
- A Personal History of Systems and Computers: Part 3
- A Personal History of Systems and Computers: Part 4
- A Personal History of Systems and Computers: Part 5
- A Personal History of Systems and Computers: Part 6
- A Personal History of Systems and Computers: Part 7
- A Personal History of Systems and Computers: Part 8
- A Personal History of Systems and Computers: Part 9