Think Black

by Clyde W. Ford

  With each new generation of IBM computers, compatibility problems arose. The programs my father wrote for the IBM 705, for example, did not run on an IBM 7080, and programs he wrote for an IBM 7080 did not run on an IBM System/360. Even if he wrote those programs in a software language such as COBOL or FORTRAN, which looked the same regardless of the computer, the underlying software that read and interpreted the program’s instructions was tied to specific hardware, which often meant that this underlying software needed to be rewritten.

  Today, most smartphone users are familiar with the need to update their operating systems, which happens, for the most part, automatically. Once updated, all of the contacts, emails, and applications that were originally part of the smartphone are still accessible with a swipe of the phone’s screen. Even if you purchase a new phone, your contacts, emails, applications, music, and other data can be transferred, relatively easily, from your old phone to your new one.

  Now, imagine if each time you updated your smartphone’s operating system, or purchased a new smartphone, everything had to be reentered by hand. All of your contacts had to be retyped. All of your emails had to be re-sent to your smartphone. All of your music and applications had to be downloaded again. When a new generation of technology is incompatible with a previous generation, it’s called intergenerational incompatibility, and it’s a sure way to kill the new technology. IBM’s product line in the early 1960s suffered from intergenerational incompatibility.

  Multiple-user environments are also easily understood. In the early 1960s, it might have cost a couple of million dollars a month to lease a large-scale IBM computer. Imagine now that a hundred students are assigned to write programs for mathematics, physics, and business classes at a university that has only one such expensive machine. Each student would punch their program into a deck of cards and add some cards at the beginning of the deck to tell the computer how to set up to perform the required calculations. But the computing environment for a program to determine a rocket launch and landing on the moon might be very different from one needed to calculate an actuarial table.

  Now each student, holding their card deck, would line up to place that deck in a card reader. One by one, the computer would read each card deck, and one by one the computer would set up and execute each program. Each student would get the results of the program’s execution, make changes to correct any errors, and then get back in line with a deck of cards, and the process would start over again. This method of computing is called batch processing, and it’s extremely slow. It would be analogous to having to shut down the word processing program on your laptop or desktop computer in order to open your email application, and then having to shut down your email application when you wanted to switch back to word processing.

  Today, if a hundred students need access to a single high-speed computer, they can each sit down at a keyboard and monitor and simultaneously access that computer. The ability to achieve this multiple-user environment comes from the underlying ability of computers to perform multitasking and multiprocessing, abilities not present in most hardware or software at the dawn of the Digital Age.

  Memory’s high cost also hampered early computers because it limited the size of the applications that could be written. If my father wrote a program that required 50 kilobytes of memory for computations and 50 kilobytes of memory to store the results of those computations, that meant his application required 100 kilobytes of memory. But what if the computer he worked on only possessed 50 kilobytes of memory total (farcical by today’s standards but certainly not unheard of in his day)? He, and all early programmers, then went through an inordinate number of time-consuming, nonproductive gyrations to handle the memory they had available: segmented programs, partial programs with instructions to load other parts, and instructions to read and write temporary results to disk storage, to name but a few.

  Where today, 100 kilobytes of memory costs a fraction of a cent, in the early days of computing, 100 kilobytes of memory could cost several hundred thousand dollars. Lines on a punch card were cheap, computer memory was not, and that was a real problem that DARPA wanted solved. Wouldn’t it be better, the thinking went, if programmers simply developed applications without worrying about how much memory they required, and computers managed the gyrations necessary to make the applications work within the limitations of the memory available?

  Compatibility, multiple users, and memory management. Three problems, from the early days of computing, with solutions that underpin the digital landscape we take for granted today. These were the abilities that DARPA sought. Without first solving these problems, there would have been no internet, no email, no Facebook, no Twitter, no WhatsApp, no Instagram, nor any of the hundreds of thousands of computer and smartphone applications that we so readily use today. Windows, iOS, Android, and the Cloud all trace their heritage back to the solution of these three problems. While many other technological innovations came together to bring about today’s digital revolution, solving these three problems remained key and involved both new hardware and software. IBM handed off many of the challenges posed by these three problems to the men and women of Project CP-67.

  By the early 1960s, my father had become acquainted with most of IBM’s diverse computer line, principally the IBM 7000 series and the IBM 1130 series. The company intended to bring out an IBM 8000 series of computers but scrapped those plans when customers balked at the prospect of once again migrating their software to meet the specifications of IBM’s new hardware (the compatibility problem). So IBM set off on the extremely bold but risky strategy of creating the System/360 line of computers, with the goal of encompassing a vast range of processing power, memory size, peripheral device support, and cost under a single unified computer architecture.

  When purchasing a new laptop today, you can first decide on the make you want, then select the processor speed, the amount of memory, and the screen size. You can be certain that the laptop, if running a version of the Windows operating system, for example, will also run an application like Microsoft Word, regardless of the laptop’s final configuration. The standardization and portability expected today were revolutionary in the early 1960s, pioneered by IBM with the introduction of the System/360 line of mainframe computers, which were first announced in April 1964. A System/360 model 30 could perform up to 34,500 instructions per second with 8 kilobytes of memory, while at the opposite end of the spectrum a System/360 model 91 could execute up to 16.6 million instructions per second with 8 megabytes of memory. While laughable by today’s standards, when a cheap cell phone can easily outperform a high-end System/360 model, the introduction of the System/360 line, with built-in compatibility between models, was a turning point in the history of computers that secured IBM’s dominance until the advent of personal computers.

  But even the System/360 line soon ran into a problem. IBM built these computers under the mistaken belief that single-user batch processing would dominate future computing, a miscalculation akin to Bill Gates’s initial dismissal of the internet’s importance. Academic and scientific users, who drove much of IBM’s technological innovation, clamored for multiuser access, known then as time-sharing systems. And so did DARPA and the US government.

  With computer speeds ever increasing, a time-sharing system served multiple users by allocating a single computer’s processor and other resources for a brief period of time to one user and then to another. Like a stick handed off around a circle, if done fast enough, the delay between having the stick would shrink to the point that each person perceived they always held their own stick. In other words, each time-shared user on a fast computer would perceive that the computer and its resources belonged exclusively to him or her.

  In the 1960s, MIT clamored for time-sharing through Project MAC (alternately known as the Project on Mathematics and Computation or the Project on Multi-access Computing). Project MAC had its offices on the fifth, eighth, and ninth floors of 545 Main Street in Cambridge, Massachusetts, in a compl
ex known as Tech Square. IBM’s Cambridge Scientific Center (CSC) occupied the fourth floor, while the company’s sworn enemy, GE’s Cambridge Information Systems Laboratory (CISL), had offices on the seventh. Listed under the name R. K. Starling Associates, the Central Intelligence Agency maintained offices on the third floor.1 When my father left for Cambridge, he worked for CSC.

  In 1963, DARPA funded Project MAC to create working hardware and software that allowed many users to access the programs of a single computer from any location—the first stage in developing the network technology that would one day become the internet. IBM and GE were locked in fierce competition for the technical lead of Project MAC, GE through its MULTICS (Multiplexed Information and Computing Service) System, which ran on a modified GE 645 computer, and IBM through a special-purpose System/360. IBM lost the first round of competition when Project MAC opted for MULTICS. Then Bell Labs, another key IBM customer, delivered IBM the same devastating blow.

  But IBM fought back.

  The company reorganized its development and manufacturing divisions, addressing problematic issues identified by Project MAC and perhaps also punishing those responsible for the company’s disgrace. Then the company commissioned a corporate-level task force to find a way of meeting this unanticipated demand for time-sharing. IBM’s task force delivered plans for a new System/360, the model 67, and with it a new time-sharing operating system, TSS/360.

  But CSC went ahead with plans of its own to build a time-sharing operating system for the System/360 line, known as CP-40 (Control Program 40), since CSC chose to modify an existing System/360 model 40. CSC needed to overcome two key hurdles in developing a working time-sharing system: stable virtual memory and a working virtual machine.

  When a time-shared user’s turn is up, they must yield the computer and its resources to the next user waiting, but the computer needs to store all the information necessary to re-create exactly where that initial user left off the next time it’s that user’s turn. This information cannot be stored in the computer’s normal memory because that memory would be needed for the next user’s tasks. So, the question became where to store all the necessary information about a user who is waiting for a turn at the computer.

  In the time-sharing systems of early computing, and in today’s modern networks, a waiting user’s information is stored in virtual memory, usually on a hard drive. While the internet is a bit more complicated than CSC’s time-sharing system, the concepts are exactly the same. Take your web browser’s cache. When you’re not actually visiting a web page, information about your last visit is stored on your computer in the browser’s cache. The next time you visit the web page, that information can be used to re-create exactly what you were doing prior to exiting the page. Your web browser’s cache is a form of virtual memory.

  CSC, however, took the idea of re-creating each user’s previous session one step further. Instead of just storing data for that user, CSC chose to use virtual memory to store a complete operating system, including data, for each user’s session. That meant, under CSC’s design, the computer would store the equivalent of a separate computer for each user between sessions, hence the name virtual machine.

  Today, the notion of a computer storing the equivalent of a computer is quite common. It happens all the time in the Cloud. In fact, that’s pretty much what the Cloud is, a lot of stored virtual machines—images of computers stored on disk drives. When a user logs onto the Cloud and is ready to use their computer, that stored image is loaded into a real computer somewhere, and it starts to run. But in the 1960s, the concept of virtual memory and virtual machines was a real game changer.

  IBM delivered the System/360–67, but TSS/360, the time-shared operating system, lagged behind. CSC saw an opening and adapted CP-40 for the System/360–67, hence the name CP-67 (Control Program for the System/360 model 67). That’s where my father came in. He worked in Cambridge on the CP-67 project under the guidance of CSC.

  CP-67 and CMS (Cambridge Monitor System), the operating system it delivered for each user, changed the trajectory of modern-day computing. DARPA dropped GE’s MULTICS System in favor of IBM’s CP/CMS solution. The first-ever networking businesses sprang up around the success of CP/CMS. IBM integrated virtual memory into its entire product line, and CP/CMS morphed into future mainstream IBM operating systems such as CP-370/CMS, VM/370, and z/VM, which are still widely used on mainframe computers.

  With the success of CP/CMS, DARPA’s early investment in Project MAC paid huge dividends. The next time you open multiple windows on your PC or your Mac, swipe between applications on your cell phone, visit an internet site, send a social media message, or access treasured family photographs in the Cloud, you have CSC and CP-67 and CP/CMS to thank. You can also thank my father.

  Yet there’s more to my father’s story with CP-67, things that remain hidden even after all these years. DARPA did not fund Project MAC for simple altruistic reasons or to benefit multinational corporations like IBM and GE. National security was at stake. Government, military, and intelligence agencies had a keen interest in the advanced technology emanating from Tech Square. Information and personnel moved freely between the organizations with offices at Tech Square. CIA briefings on the technological developments at Project MAC happened regularly. Robert Creasy, who once worked for Project MAC and DARPA, left to work for IBM, where he spearheaded the development of CP/CMS as the head of CSC.

  By the mid-1960s, IBM’s history of working with the military stretched back at least as far as the Mechanical Records Units (MRU) division of the US Army and the “IBM soldiers” in World War II. After the war, Watson even attempted to establish his own private intelligence agency and offer contract services to the government. His efforts were thwarted when, in the late 1940s, the White House and Congress established the CIA.2

  Secrecy suited my father. Once he understood that IBM would not publicly advance his career, secrecy afforded the empowerment he would not find elsewhere within the company. Secrecy held the illusion of power.

  He said little about his work with CP-67. Everything about his time in Cambridge was, in his own words, “hush-hush,” “top secret,” and to be taken to his grave. All I have in my possession is a carbon copy of a letter, dated May 8, 1972, from a manager of the CP-67/CMS group at Technology Square in Cambridge, to a woman named Gayle Johnson, apparently my father’s manager at the time, thanking her for providing the group with my father’s services. “His output and performance while on assignment here were of the highest caliber,” the letter says. In the upper right-hand corner of that letter, someone had crossed out the words “IBM CONFIDENTIAL,” the company’s equivalent of a top secret classification.

  While I may never know if, and under what circumstances, my father visited the offices of R. K. Starling Associates on the third floor of Tech Square, I do know there were too many coincidences between my career at IBM and his to dismiss his involvement with the CIA out of hand.

  After a year or two working as an IBM systems engineer from my office in the New York Federal Reserve Building, I simply grew bored. Helping programmers find bugs in core dumps became a mind-numbing exercise that I performed without much thought. I stopped reporting in to my office, and I stopped going to work at the Fed. Instead, I spent most of my time at IBM’s New York Data Center at 909 Third Avenue in New York. There I’d log in to an internal time-sharing service run out of an IBM laboratory in Armonk, New York. In those days before CRT and LED screens, I could only use a modified Selectric typewriter to interact with the computer. I’d type in something, wait, and a few moments later the Selectric ball would whir and slowly spit out a response.

  I taught myself APL (A Programming Language) and worked on self-assigned mathematical problems in matrix and linear algebra. I logged in using my IBM employee number, and I ran up quite a bill. When an accountant at my IBM branch office discovered the tens of thousands of dollars of his internal budget that I’d consumed, I thought I’d be fired, but instead he wink
ed and told me not to worry, for no one would ever know.

  After that, I switched to an IBM 1130 computer at the Data Center that did not require me to log in. My interest at the time was artificial intelligence (AI), and I programmed the 1130 to play the African game of Ware to better understand AI concepts. I’d often work at the Data Center until the wee hours of the morning, grab a few hours of sleep in my apartment in the Bronx, and go back to the Data Center early the next day. Nerd? Geek? We didn’t use those terms in the early 1970s, but if we had, they surely would have described me.

  I may have thought my actions were not being tracked by IBM management, but I was wrong. After I had hung out at the Data Center for nearly eighteen months, my manager called me in for a performance review.

  “You haven’t been at your job,” Conrad said.

  “I know. I’ve spent most of my time at the New York Data Center.”

  “You’ve run up quite a bill. We know what you’ve been doing. We just don’t know why.”

  “I’ve learned APL. I’m working on an artificial intelligence project.”

  “You don’t get to choose. I hired you to work at the Fed.”

  “I’m bored. I’m not using my mind.”

  “That’s not my concern. Your lack of performance for this office is.”

  “I need a challenge, not a core dump.”

  “You need to get back to work at the Fed.”

  “There’s a job opening teaching at the Advanced Education Center. I want that job. I’d be good at that job. It would stimulate me, challenge me.”

  Art’s face went red. “What?”

  “A job at the Advanced Education Center.”

  “Who told you about this job?”

  “The Advanced Education Center’s in the same building as the Data Center. I’m around there. I hear things. I just know.”