Return to EarlyGE-Computers
My memory for dates is fragile or missing for the events of half a century or better ago. I have put together, where I was personally involved, those projects that bore on the development of the time-sharing era. It starts with the creation of one of the first commercial operating system that was developed and put into widespread use outside of the closed industrial and academic communities. The direct access TIME-SHARING (T/S) available in the 1960 to 1999 era is, from a users point of view, the same as what is now called “CLOUD COMPUTING. The difference is simply that the CLOUD users terminal is smart and our T/S user terminal was dumb. I was involved in the design, coding, integration, debugging, testing, and then the use of the following T/S systems:
Don Fry history working in the time sharing development area.
June 7, 2018
1961: I went to work for General Electric Computer Division in Phoenix Arizona as a Test and Diagnostic programmer in the engineering unit of the 200 line of GE computers. I analyzed the logic and design primarily for the DataNet 30 (DN-30) communications computer. I programmed (in machine language) test for all of the communications functions for the control of not only telephonic start-stop interface circuits but related external functions such as automatic calling, voice answerback, and voice recognition. I programmed various test for the peripherals and mainframes of the GE 200 line of computers.
The DN-30 and the GE 235 mainframe systems were the computers used for the Dartmouth Time Sharing System (DTSS). In 1962, John Kemeny and Thomas Kurtz at Dartmouth College submitted a grant for the development of a new time-sharing system. Its implementation began in 1963, by a student team under the direction of Kemeny and Kurtz to provide easy access to computing facilities for all members of the college. In May, 1964 the system began operations. It remained in operation until the end of 1999. DTSS was originally implemented to run on a GE 225 computer with a GE DN-30 as a terminal processor. Later, DTSS was reimplemented on the GE-635 still using the DN-30 for terminal control. The 635 version provided interactive time-sharing to up to nearly 300 simultaneous users in the 1970s, a very large number at the time.
1962-1964: Six of the group of programmers employed in the engineering unit that later became the so-called OKIE CODERS (OKIES) worked with two of the DTSS student programmers on a “bootleg” project within our engineering section, to build a working commercial timesharing operating system from the public domain DTSS Operating System (OS) that came from Dartmouth College. This was mostly debugging error ridden OS code for the GE 235 and DN-30 written by students and designing and implementing all of the supporting programs. This was accomplished using our engineering prototype CPU units scattered over the GE factory floor. We also had to teach operations how to operate this system designed to run continuously 24/7. We even had to write a brief BASIC language teaching book because Dartmouth used blackboards and loose leaf manuals to teach students the language and commands to use the system remotely over telephone lines at the standard teletype speed of 110 bits per second. After cleaning up the DTSS system we placed teletype terminals in volunteering GE employee homes as well as terminal rooms at the GE plant. This gave us actual users that enabled debugging of the system as well as allowing us to write and debug the accounting and billing routines so that the system could be brought up and sold by the GE data centers as the revenue producing system called the GE TIMESHARING SYSTEM. The system was used and sold by GE internationally for over twenty or so years with upgrades to the hardware as computer circuits and iron advanced.
1965: Developed and implemented an interactive testing system for the GE 645 (MULTICS) special hardware in coordination with manufacturing quality control and installation testing with Dr. Corbato at MIT and Dr Vyssotski at Bell Labs. This was called PROJECT MAC and used an extremely fast firehose drum for memory paging. The first complete MULTICS hardware was delivered to Bell Labs about 1965.
1965-1966: I was one of six OKIES hired by the IBM Data Processing Division head, F.G. (Buck) Rodgers, to write a timesharing operating system (OS) for the IBM 360 line of computers so that IBM could compete with GE and TIMESHARE INC. in the computer timesharing public marketplace. IBM had a timesharing product that ran on the 1401 mainframe and later the 360 line mainframes called QUIKTRAN. It was a dog and although it was a real T/S remote access system it was not released to the public as a service until March of 1967.
We OKIES worked under a contract between a New York City based software body-shop named COMPUTER APPLICATIONS INC. (CAI) and IBM. We reported verbally to the IBM’s Head pf Data Processing BUCK RODGERS. The original contract was for one year, to produce a system allowing 128 to 256 simultaneous users to run the QUIKTRAN 2 version of the Fortran language. It was to operate as a freestanding T/S operating system on the IBM system 360 models 50 and 65. It was originally planned for our small group to operate from IBM facilities located in New York City but was negotiated to operate from an IBM leased facility in downtown San Jose, California after we refused to relocate to NYC. The six OKIES all moved from our GE jobs in Phoenix, Arizona to San Jose. We were joined by an administrative manager from CAI and one woman who wrote a BASIC and a FORTRAN compiler while we wrote the operating system, all in machine language, for the IBM 360 system. Two more ladies from New York joined we OKIES as functionary programmers. As the software progressed we hired two more programmers from GE in Phoenix to join us to complete the OS. In addition to designing and writing the code we set up and conduct alpha and beta test using live users, organized and printed documentation, wrote the command and language manuals, and debugged the OS as coding flaws were discovered during the beta test. IBM employees assigned to our project grew to over 30 persons which included support administrators as well as programmers (which we trained on our OS code so that they could provide ongoing IBM support) but thank goodness they left our group alone except for frequent meetings where we provided progress reports.
We completed and turned over the system to IBM on-schedule, on-budget, and various beta test proved that 128 simultaneous users obtained designed response times to their execution of their remote task. This product was never released to buyers of IBM hardware products as a free standing OS.
1967-1968: IBM at the direction of BUCK RODGERS ask the OKIES if we would contract to take the freestanding T/S system and make it run efficiently with it’s standard batch operating system OS. We could not make any changes in it’s OS but we must preserve the blazing efficiency of our T/S system. The OKIE CODERS incorporated ourselves as a company named REACTIVE COMPUTER SYSTEMS (RCS) with the six OKIES as owners and about five other ex-GE persons as additional employees. After a quick assessment of IBM OS and several meetings with the original designers of IBM OS, we agreed to contract with IBM for RCS to perform the conversion and all necessary other task as assigned by IBM.
While all of this was going on IBM had established and operated a unit to produce a operating system they named TSS to compete in the existing T/S marketplace. TSS had cost many millions of dollars, had almost 100 staff, and spent three of so years and produced nothing competitive. IBM just did not have the software experience and expertise to design an on-line interactive multi-user operating system and TSS became too all encompassing to function efficiently. We were funded monthly by IBM’s BUCK RODGERS in competition with this TSS project and we jointly made monthly progress reports to him verbally.
We thus contracted with IBM to convert the IBM OS with a one line change in their OS and using their standard control interface standards to run the free standing machine language code we had written to operate under IBM’s standard OS. As a final performance test I traveled to the IBM facility at Westlake California where a IBM model 65 as well as a Model 50 mainframe were up and running. I had arraigned to have 256 RS232 communications cables manufactured enabling me to connect the model 65 and model 50 communication modules back-to-back enabling me to run software we designed on the Mod 50 which simulated 256 remote users. Our test software recorded the individual response time and all fell within acceptable limits. This was with the model 65 tuned to provide our T/S task allocated just 50% of the available memory cycles and with the other 50% being allocated to various batch jobs being ran simultaneously. IBM allowed us to write a command console only master command function to allocate memory cycles between our T/S job and all other “batch” jobs to run simultaneously on the system. This product was called CALL/360 OS during production and testing. This conversion was completed on-schedule and on-budget. To my uncertain knowledge, there was never any user code that broke the security of this operating system and thus broke the security of any users data even though all of the operating system code was open and available to anyone running the software.
We also conducted several months of training of IBM marketing and sales management persons from both the U.S. and IBM WORLD TRADE to go out and sell the product which was officially named CALL/360. The system was unbundled and was made available free to IBM system users. It is unknown how many large IBM mod 50 and 65 system owners used CALL/360 internally or as a public on-line revenue producing facilities but it must number in the thousands. RCS provided one of our employees to go to Paris France for over six months and make all necessary changes to the French version of CALL/360 terminal I/O code to enable its use with the French telephone systems. Over 35 large universities worldwide used the software system which was unbundled and free for their use. The University of New Mexico used CALL/360 for over thirty five years for student, department, and professional use until it was supplanted by micro based systems.
IBM then ask us to produce a design write up explaining why we designed each major function of the software as we did. This took several months and four of the OKIES produced this large document. We were called upon by IBM several times
As we performed these additional task, all IBM software products were “unbundled” under the US Federal Court anti-trust decree and were transferred to the wholly owned subsidiary of IBM named Service Bureau Corporation (SBC) much to the disgust of most of the IBM employees that were affected and were connected to our project. RCS was called upon several times to unlock and suggest fixes to various functions of the CALL/360 system which we did as a service to IBM.
1969-1971: REACTIVE COMPUTER SYSTEMS (RCS) became a wholly owned subsidiary of MEMOREX corporation and all of the employees became Memorex employees. The subsidiarary was named MEMOREX REACTIVE COMPUTER SYSTEMS (MRCS). We were acquired to develop a time-shared capable CPU and associated communications hardware to sell as a system using Memorex existing peripheral hardware. We were to then build an operating system to run all of this gear. After a year or so with nothing happening myself and several other of the original OKIES left the company and went our separate ways.
1972-1999: I developed a business plan to buy a minicomputer based timesharing system, write small business back office applications such as payroll, accounts receivable, payable, and general ledger, sell small businesses an acoustic coupler and keyboard printer terminal such as a model 35 teletype unit. Each business used their existing or leased a new telephone line and paid me to allow them to hook up and send data to me and receive checks and reports that were printed at their terminal as well as storing, securing, and backing up their data. I found that I could not purchase business software capable of running on existing minicomputer hardware. But having taken the one required business course in engineering college, and having hand calculated and written payroll checks for our little company, I would simply write a general purpose payroll and job-costing application program in the Basic language. I was still writing payroll software changes due to tax laws 30 years later.
I developed a business plan, moved to Santa Fe, New Mexico, found investors to share the start-up years cost, purchased a BASIC TIMESHARING INC (BTI) 3000 minicomputer system with 16 modem ports, Two 7.5MB removable hard disk drives to enable full disk backup, and two BELL 103 telephone modems connected to two computer access telephone lines. The CPU unit was a HEWLETT PACKARD 3000 minicomputer. I also rented a AT&T model 35 teletype machine which had a keyboard and printer.
I then started writing payroll computer code using the BTI interpretive basic language and seeking business customers. Twenty five years later I had two BTI 3000 computer systems, one 30MB hard disk drive, 32 modem ports, two ¼ inch cassette tape drives for backup, Ten 300 baud modems, two 1200 baud modems, twelve computer access telephone lines, and two DIGITAL EQUIPMENT (DEC) DN30 keyboard printer terminals converted to run at 2400 baud.
I had two employee partners, one a salesman business bookkeeping troubleshooter, and one a computer engineer like myself who had been one of the CALL/360 OS system developers. We had, by the way, over one million lines of business applications code written in BTI basic language. There were over 20,000 payroll checks, 5,000 accounts payable checks, 10,000 payables statements, and 250 sets of bookkeeping reports printed monthly by over 350 small business firms using this system. We ran 24/7 365 ¼ days a year with only two computer systems failures over the years and never had a breach of security of our or customer data. Beat that Mr. Gates! There were many hours of general power failure outage over the years but never once had a scrambled disk file as a result of a power failure. Twice our computer room air conditioner failure resulted in shut downs to prevent temperature damage to the hardware systems. We had only one instance of fire in our computer cabinet and that was the result of an lightning strike induced capacitor short in a modem. We had zero software system failures thanks to a BTI rock solid operating system and hardware design.
1999: The microcomputer age started to happen and after buying a PC and watching micro computing develop over a period of years we decided that we had been there and done that and did not want to go through the birthing pangs of another computer system development. Using micros we saw no way to protect our software from theft and most importantly protect customer data from unauthorized access. We wrote papers, books were published, lectures were given but Mr. Gates, Mr. Allen, and others did not listen or understand. Thus the present state of affairs in the computer security department.