CAI in Manhattan occupied several floors in a building on Madison Avenue at 55th Street, just four blocks from the Service Bureau. Happily, the offices were far more comfortable, and the management much less stuffy. One of the best aspects of the organization was the large proportion of talented women, so I made some lasting friendships.
Possibly one reason for the pleasant atmosphere was the second-level manager, Jerome Wiener. He was a natural manager, and had no trouble with assertive women; his wife was a successful hardware engineer. Also his immediately prior experience, with overall responsibility for large systems engineering at GE, was undoubtedly instrumental in obtaining an important contract later on.
My first assignment at CAI, lasting a few months, was as on loan to IBM's ill-fated Time-Sharing-System (TSS) project. It was a huge project, but was eventually cancelled. My responsibilities there related to supporting the development of code for the intended hardware, probably by translating among assembly codes, but I don't remember the details. However, after a few months I was asked to instead work on a new CAI contract, to build a compiler for "SPL", a "Steam Power Language".
This project was based on a contract with Leeds & Northrup (L&N), a process-control-related firm. L&N had defined a language for controlling a steam power plant, with the initial deployment to be at the Munmorah (Australia) Power Station (since destroyed). The target hardware was the SDS 920. The machine was presumably chosen, at least in part, because it could be obtained with a large number of built-in interrupt levels (see [SDS_1] p. 48), making it suitable for the purpose.
The Machine, in Different Places The project had some aspects which, although annoying at the time, are slightly comedic in retrospect. The SDS 920 was a relatively small computer for the time, and we planned to install it at the Manhattan office. But that turned out to be impossible, because the machine didn't fit into the building's elevators. So we rented a dismal ground-floor space in the borough of Queens, and our initial preparation for the project involved the use of buckets, mops, and detergent to make the place roughly habitable.
Now the SDS 920 wasn't like a 7090. Input, for example a program to be assembled, was on "paper tape": a long strip of paper with holes in it, read by shining light through the holes. The tape, prepared using a teletype or flexowriter, tended to tear easily, but that was ok... the tears were easily mended with scotch tape. Also, the tape was wound up into little rolls using a hand-held, battery-operated paper tape winder, whose internal battery connections tended to separate. But this was also easily fixed .... by inserting a dime to bridge the gaps. The one problem we couldn't do anything about was that the electric power service in the area was inadequate, so people returning from work in the afternoon sometimes caused power surges which, in turn, interfered with any job in progress, which had to be restarted from the beginning. This was a serious problem because the machine was extremely slow, and assemblies took forever.
The other less-than-optimal circumstances related to the Leeds & Northrup plant in North Wales, Pennsylvania, where we worked part of the time. One problem was that I, being a city kid, had never learned to drive, and the train connections were not very good. So I had to spend some weekends with my learner's permit driving around NYC and parking lots in North Wales. Also, we were asked to make sure that the system would work in some of the environments to which the machine might be subjected. Both very hot and very cold. And we could do so by doing our work in the little machine room built inside their plant. Very high temperatures were generated artificially. Very cold temperatures were obtained by opening an outside door to the Pennsylvania winter...
The Compiler When I first tried to recall what role I played in the development, I remembered only writing the arithmetic expression analyzer. But, looking at looseleaf binders containing my design documents and code listings, it seems that I implemented all SPL statements containing arithmetic or logical expressions, as well as other parts of the compiler. However, I had little to do with the process-control aspects of the language.
The expression processor may have been especially memorable because it may have changed my way of thinking about programming... beginning the process of moving from subconsciously considering my work as mostly writing and organizing procedures clearly and logically, to consciously realizing that there were significant choices to be made among methods, and new ones to be developed (and, eventually, noticing that the most fun was working on problems that you decided to address).
The method I used was suggested by a senior technical member of the CAI organization, and was the "shunting-yard" algorithm originated by Edsger Dikstra [RAIL_1], but I probably learned it from a readable account in a book by Randell and Russell [RAIL_2, p.149ff]. The method was straightforward and very fast, and tended to result in good machine code by limiting the amount of register loading and storing required. (Note: the Randell and Russell reference provides direct access to the book, a classic, which also contains a history of expression processing methods to the time of publication.)
The result of the method was usually a suffix form (often called "reverse Polish") from which instructions that honored precedence rules could be easily generated. So, for example, given the expression "A + B ** C * D" the resulting suffix form would be "A B C ** D * +". Generating code from that form involved cruising through it and (a) finding a triple consisting of an operator immediately following two operands and then (b) generating the associated operation, and then (c) replacing the triple by a reference to the result (a temporary location or register). So for the foregoing example the sequence would be:
| Generated Code | Remaining String |
| T1 = B ** C | A T1 D * + |
| T2 = T1 * D | A T2 + |
| T3 = A + T2 | ... |
The algorithm proper is called the "shunting yard algorithm" because of its resemblance to shunting railroad cars in a train yard. In the method, the symbols of the expression are scanned one by one. In a nutshell, all operands are added directly to the output suffix string, but some operators are temporarily "shunted" to a stack, where they are held until operators for operations which have to be performed first are added.
Here’s a description of a reduced version of the algorithm (which can be skipped... :-). It is reduced in that (a) the only explicit operands used are numbers and scalar variables, (b) no explicit parentheses are accepted, and (c) all operations are considered “left-associative”, that is, given a sequence "x op1 y op2 z", with op1 and op2 of equal precedence, op1 is performed first. ( This is generally assumed by all languages except for exponentiation, **, where some languages differ.)
Given these restrictions, the shunting algorithm is as follows: Start with the input string of symbols, an empty stack, and an empty output string. Then,
So, for example, given our input string A + B ** C * D, the successive states of the output string and stack would be:
| Output String | Stack (top is at end) |
| A | | |
| A | | + |
| A B | | + |
| A B | | + ** |
| A B C | | + ** |
| A B C ** | | + * |
| A B C ** D | | + * |
| A B C ** D * + | | |
Towards the end, or at the end of the SPL project, we began work on what eventually became the CALL/360 Timesharing System.
In NYC. In early 1966 IBM requested proposals for a "360 Quiktran", i.e., a 360 version of the 7040 system, and we began work on a proposal sometime in the spring. Jerry Wiener, the CAI manager involved, had a natural advantage in this, because he had once been the high-level manager responsible for the GE timesharing work, which was closely related to the Dartmouth Timesharing System (DTSS).
Backing up a bit, because it has been a while since the the 1960s,
I don't recall the exact sequence of events that autumn related to the CALL/360 project, but they included the following:
While I doubt that I influenced the decision to initially provide BASIC, I'm pretty sure that I was involved in the decision to build a compiler rather than an interpreter. Both decisions made sense. With respect to language, as in the case of the Dartmouth System, with BASIC there was a wider prospective audience, beyond the scientific community. With respect to compilation, first, because BASIC is a relatively simple language, and programs were expected to be small, it was likely that debugging could be successfully accomplished by insertion of PRINT statements at points in the program; a large set of debugging facilities would be overkill. Also, based on my experience with expression processing methods, I knew that an extremely fast compiler for BASIC could be built. Finally, the large number of addressing registers available on the 360 would facilitate structuring the compiled programs (and the compiler itself) so that they could be instantaneously interrupted and later restarted at other locations in memory, contributing significantly to scheduling flexibility.
After the project proposal had been accepted and the rough initial deliverable identified, work commenced on the project proper, which was initially named "RTS" (Remote Terminal System). There were managerial developments: Jerry Wiener left CAI in September, and project-specific managers were named, for the project as a whole, the operating system, and the compiler. The compiler manager was .... me. Meanwhile, quite a few people left CAI, some to join a company founded by the former head of the Quiktran project, John Morrissey, and some to join a startup headed by Jerry W. I then spent the remainder of the year doing a rough design for the compiler as a whole, and, most importantly, of the interface between the operating system and the compiler and compiled programs.
In San Jose. First, the place. In 1967, "Silicon Valley" was just getting started. So to someone who had been coping with Manhattan for many years, living there seemed a bit like being on vacation: great climate, little traffic, good affordable housing (with swimming pools and parking), and supermarkets overflowing with magnificent produce from the Central Valley. Lots of open space, and forested mountain hiking trails in easy driving distance. Also, the "office" for us found by CAI added to the illusion of not-really-at-work; an old Spanish-style house complete with kitchen (the computer was in an IBM office in downtown San Jose).
As far as the others on the project, some, from Texas and Oklahoma, were fascinating to me, and many were very friendly and kind. Although they did think my responsibilities a bit strange for a female. One of the (several, in sequence) managers of the overall project once introduced me as the "ho ho, honcho of the compiler".
But we of course we weren't on vacation. I devoted most of my time to the overall framework and enablers, including (a) detailing the specifications for the interface between the operating system and and the compiler, which was intended to serve not only for the BASIC language processor, but for others in future, and (b) building a dummy "executive", so that we could develop and test the compiler while the operating system was still under development. The interface specification provided for instantaneous interruption and relocation of language processors and executable programs, both during compilation and during compiled-program execution, using only a very few cells to locate the content of critical addressing registers so that they could be updated by the operating system. The specification also detailed the dynamic aspects of communication between programs and the operating system, for example to provide for various aspects of input/output, using standard service calls (SVC).
The others implementing the compiler needed little supervision. At my suggestion Ed Burfine, from Stanford, implemented the shunting-yard algorithm for expression processing and extensively documented his implementation. Bill Codeanne adapted the 360 Fortran libraries to our needs, and, in the process, found errors in the math routines and returned the corrected versions to IBM. After the project, he began a long career with IBM proper. John Alderete joined the project late, and did many kinds of needed implementations and documentation. One other person, whose name I forget, made an unforgettable contribution. He was a "quality assurance" person for the project as a whole, and absolutely delighted in finding problems; people would arrive in the morning to find little notes on their desk, written in accusatory tones.
At the end of the year, with the BASIC compiler up and running well (and very fast), I had a decision to make. CAI had paid for the move to California, and we had agreed that they would also cover the expenses for a return to New York at the end of the year, but not later than that. So I had to decide whether to continue working on the project or return. I chose to return...
CALL/360 Aftermaths The system was announced in June of 1968 ( see ad in the Wall Street Journal of June 13 of that year). Meanwhile, work continued in San Jose, adding Fortran and PL/I languages and moving the system from DOS (an early 360 operating system) to the primary 360 operating system, OS/360, so the time-sharing system was renamed "CALL/OS".
Also, there were two major organizational developments. First, ownership of the IBM Information Marketing Division, which included Quiktran and CALL/360, was transferred to the Service Bureau Corporation subsidiary [SBC_1, SBC_3]. And then, in 1973, as part of the settlement of a suit brought by Control Data Corporation, SBC was sold to CDC [SBC_2]. I heard it said at the time that CALL/OS was what made SBC sufficiently valuable for this to be an option.
Returning to NYC, I found CAI a very changed place, with most of the people I knew having left. I also quickly realized that I really didn't want to stay in New York City, and so requested assignments that wouldn't involve long-term commitments. So I ended up in a department devoted to statistical applications, mostly for purposes of market research, but there were also some other foci, including some stock-market prediction work.
My primary responsibilities involved short term contracts to convert the results of marketing surveys into formats required by standard statistical analysis functions such as regressions, analysis of variance, etc., and to return the results of the analyses. The surveys often included two types of questions: demographic and general questions about the subjects, and questions about their attitudes toward the product or product type, and the primary purpose of the surveys was to find correlations between answers to the two types of questions. This could have its humorous aspects; I recall sitting in a very elegant ad agency conference room listening to a psychologist explain why people who suffered from backaches considered some cola drink (Pepsi? Coke?) to be expensive. (Wouldn't/couldn't buy a good mattress?)
One quirky assignment I rather enjoyed was to place advertisements in a magazine. The problem was as follows. LOOK magazine, a periodical with a great deal of photography (similar to LIFE) sold different editions in different parts of the country, with each edition including an edition-specific group of pages containing ads purchased by regional advertisers. The point of the assignment was to limit the cost to the magazine of the pages for these ads, by placing them on a minimum number of pages. (Short, general-interest material was used to fill the spaces between ads). Possible placements were constrained by rules relating to size, colors, and subject matter. As an example of subject-matter constraints, ads for alcoholic beverages could not be placed near or facing ads for automobiles.
The method used involved a kind of random walk. A sequence of runs were made, with each run placing all the ads by selecting them in a random sequence, and placing each ad as closely as possible to the already placed ones, while still observing the rules. After a given number of runs with no improvement shown, the placement which had resulted in the minimum number of pages was chosen as the result.
Anyway, I knew throughout the year that not only did I not want to continue working in NYC, but that this was just a sort of time-off from the kind of work that interested me; in a nutshell, doing work more fundamental to computing than building applied math applications. Also, it started to look like CAI was in serious financial trouble. So towards the end of the year I began to look around. I had several attractive alternatives to choose from, and decided to return to Northern California, joining the ACS project...