The time now was the early 70's. I had started my career at IBM in the late 60's with the intention of designing large mainframe computers. That was about to change - and it wouldn't be the only time things changed during the course of my career!
At the time, the mission of the Kingston and Poughkeepsie NY laboratories was linked. But our executives had something new in mind, and they severed that connection. Kingston would now be the home of the Small Systems and I/O (Input/Output) effort. The intent was to develop custom small computer systems (also known as minicomputer systems) tailored for specific industries, such as the banking industry or the insurance industry. This was about as far from the large mainframes as you could get.
That was the bad news. But the good news was that we were going to develop something new and wonderful from the ground up. No prior baggage or preconceptions. It was in fact a very stimulating time.
The primary concept was to develop standardized hardware and software subassemblies that could be used by the various industry-oriented groups. The industry groups would integrate these components and then provide the unique software and hardware for their particular industry. The name of the microprocessor family used in these devices was the Universal Controller, or UC.
The UC seemed to be a very minimal processor implementation for those of us used to the large mainframes. Yet we were to learn over time that it was actually a very advanced architecture when compared to the early Intel microprocessors such as the 4004, 8008, and 8080. On the other hand, these were single chips, and the UC was not yet a single chip.
I wound up in the area that would develop the programming tools for use with the UC processors. The only computer "language" available for the UC at that time was straight Assembler. I won't bore you all with what that means, but it is essentially just one step above programming in the actual machine code (ones and zeros) of the processor. Complicating the issue of program development was that no actual hardware existed to test the programming on - thus we had to develop software simulators (running on mainframe computers) to allow the programmers to debug their code until the hardware actually arrived. This was my piece of the action.
The goal was to have an interactive simulator, and that implies that you couldn't use punched cards - we needed an online terminal system, something that wasn't commonly available in that time.
Working with our local computer center people, we stumbled upon something called CP-67/CMS, which was another of those things developed by an area in IBM (the Cambridge MA lab) as a scientific development project rather than a formal product. CP-67 allowed a number of users to use a computer concurrently, each thinking he had his own computer, or virtual computer. Best of all, you could access CP-67 from a typewriter-like terminal, remote from the actual mainframe computer that it ran on. Thus, we could have people all around the Kingston site working on these tools at the same time.
The critical timing of our task was that we had to finish our work (i.e. the tools) before the industry groups could do their work. Within a fairly short amount of time we had developed a fully interactive suite of program development tools for the UC. As I look back, it was some of the best work I had ever done. Ah, the good times…
(Bob Seidel is a local computer consultant in the Southport / Oak Island area. You can visit his website at www.bobseidel.com or e-mail him at bsc@bobseidel.com).