1967

The origin of the Bull "New machine" may be traced down to the cancellation of the BULL-GE 140.

The G140 project was the first system the design of which was started at Bull General Electric after the GE merger of 1964. Other systems such as Gamma M40, Gamma 10 and GE-55 were sold by B-GE -and the latter by General Electric in the US-but designed at the time the company was still Compagnie des Machines Bull.
The 140, later announced as GE140, was a medium range system 16-bits wide designed for tape and disc environments ; the disc version was never physically delivered to customers. The design of its software was later "exported" to the CII for the design of CII IRIS 50, the software chief architect of the 140 software being François SALLE.
Initially, the 140 had been designed as a member of a common product line containing  GEISI –General Electric Information Systems Italia– GE115, designed also before the GE-Olivetti merger, that was sold very successfully by Bull General Electric

However, the G140 program was also  competing in fact with another GE system, a 24-bit second-generation computer named the GE400 developed in Phoenix AZ. As that of the GE-400, the G140 technology was conventional built on discrete transistor  components, although Bull hardware labs had designed modular elements called "mini-modules" that could have been eventually integrated in ICs.

The G140 program was canceled by the end of 1966  a little bit after its marketing announcement in Bull-GE territories. Among reasons of the cancellation were the internal competition with GE400, the lack of line image of the GE-100 and the relatively high development cost combined with  Bull General Electric's lack of money. It should be remembered that in this period, computers were leased from the manufacturers and manufacturing new computers was, for the company, a capital drain that required several years to recover.
The 140 cancellation caused a big turmoil in Bull's French Marketing and  in Engineering. Bull-GE  was very quickly deserted by many of its engineers who joined the Government subsidized CII that was just been formed.
The end of the 140 project was that the Czechoslovakian company Tesla acquired the license of G140 and the manufacturing rights for that system. A few hundreds were produced in the late 1960s and the early 1970s.

Launch of project "Charlie"

 As a conservative measure to keep some engineers on board, BULL-General Electric, with GE agreement, assigned to Pierre DAVOUS, assisted by Georges LEPICARD, an exploratory mission to specify a line of medium sized machines that could be sold competitively with IBM 360 –the IBM product line then emerging then as a definitive success–. By medium-sized machines was meant systems at IBM 360/50 level and below, excluding what used to be the IBM 70x/70xx class of customers. It also excluded systems derived from accounting machines that were to be the then succesfull GE-55 machine. More explicitely, the line should be substituted to the GE-100.

As its IBM competition, it was planned that the line of products would have to be micro-programmed, a technique that the Bull team was the only one having experimented within GE with the projects  M40 and GE140 (and the GE-55). Other GE -even GEISI- systems were hard wired.

This project received the name of "Project CHARLIE". A few Americans from Phoenix engineering, noticeably Izzy EPSTEIN, joined a research team of around 20 French people.

Some of the basic design options of the DPS7 have been taken during this study. Particularly, it was decided to adopt an architecture now known as CISC using 32 bits registers à la S/360 and to introduce some MULTICS segmentation features.
It was also considered that real-time transactional applications should merit a firmware implementation of the process (presently named threads) dispatching mechanism. A first draft of the instruction code set was established. It was planned to stay with a classical model of a Van Neumann architecture, even if software was inclined to separate code from data. After a minimal evaluation of an interpretative language -such as BASIC-, it was decided to keep a more conservative approach of having compilers preparing binary code.
The different models of the Charlie were contemplated to differ essentially by the width of their data path (16 and 32 bits).

During this period at mid-1967-, GE hired an ex-IBMer, John HAANSTRA, as vice-president for Strategy.
He took a direct interest in the design options of the CHARLIE project. John HAANSTRA recommended that the peripheral controllers (PCP Peripheral Control Processors) be micro-programmed, avoiding special logic as much as possible, and the Bull URC -- that was later followed by its cousins like the Phoenix MPC and the NEC URP, was initiated by Henri VERDIER team on the base of J.HAANSTRA recommendations.

In parallel, technology studies were initiated: while the choice of integrated circuits was obvious (RCA had already shipped its Spectra70 line), several solutions were possible for the transistors types. GE had started in Schenectady the study of CML – a variant of ECL, slightly less power-hungry– and CML was a potential candidate for the new line of systems in parallel with TTL.
Another assumption was that main memory would be still implemented with magnetic cores, what impacted significantly the cost of the system and put considerable pressure on software design.

1968

General Electric L178 Product Line

Outline

A GE Management review took place at the end of 1967 and it was decided that the Bull-GE Charlie study should be the base of a modern GE product line essentially targeted to replace GE-100 and GE-400 product lines.

This product line should have been designed jointly by GEISI, Bull and the GE400 team of Phoenix. The GE600 team of Phoenix was then busy fixing design and implementation problems in both the GECOS3 and the MULTICS systems and was let apart of the new design. On the contrary, ASTO research center in Phoenix, directed by John WEIL and Mauro PACELLI, was to be deeply involved in the project.

It was decided to review the options of the Bull study (project Charlie) and to launch a project called L178 product line composed of three models:

• E120 as a 16-bit low-end machine assigned to GEISI,
• R370 to be developed by Bull General Electric
• W108 a more powerful system to be developed by GE Phoenix.

A strict security system, à la IBM, was instituted for the new design. Code names were formed from the initials of the project manager and documents were classified as GE class4 for all business planning and financially sensitive matters and class3 for technical matters. Class4 documents received a number for each page and they were distributed according a centralized and nominative list of distribution. Class3 documents were distributed according "need to know" lists of distribution. It seems that no leak to the press or to the outside occurred during that phase of the design .

The project  started effectively  in January 1968 under the effective direction of Eugen R. WHITE as project manager reporting directly to John HAANSTRA. A coordination team was assembled in Phoenix ;
the chief architect was Georges LEPICARD from Bull-GE,
the software project leader was Leroy ELLISON from GE
Some Bull hardware architects from BULL --G.BARONNAT and G.de PONCINS, joined the Phoenix team and stayed there with Georges Lepicard for around one year.

Specific program managers were assigned in the different organizations to coordinate local work and to report to the overall program manager. Jean-Pierre HARDY was named program manager for the R370 to be developed by Paris.

The architecture was coordinated by George LEPICARD and discussed between the CPU architects, the compiler designers of ASTO and the Paris software people for the kernel (then called nucleus) requirements. The first draft of the "Interior decor" –this term was coined at this time by ASTO software people– was published by September 1968.

E120 Compatibility. Origin of Level 62 divergence

The E120 architecture was in october 1968 "accepted" as being a "subset" of the main line "interior decor". The arguments were that the cost of the segmented architecture implied by the associative memory penalized abusively the cost of E120 processor and that a low-end machine should keep integrated peripherals and should not support the implication of I/O channels management. While real, the decision to diverge simplified the management of the project by not addressing the long rivality between the French and the Italians.
Consequently, a large autonomy was given to the designers of what became eventually  the Level 62 about the design of their architecture and their software. The divergence between DPS4 and DPS7 took place in 1968! However, at that time, it was still implied that the upper range of the line should be able to operate in the lower level "mode"; this specification was later dropped.

During the Charlie project, it was envisioned that the E120 decor had to be the same as the one of the PCP, so that a single engine could be used on the subsystems and on the lower end of the line. This last approach was abandoned by November 1968, at Paris request to use a minicomputer 16-bit decor instead of a variable length "main frame" decor for the PCP.
The E120 project subsisted through the GE-Honeywell merger and gave birth to the Series 60 Level 62 product line to be followed the DPS-4 and 4000 until the mid-1980s.

Software

A proprietary high level Implementation language for software development was planned :   Q-language, an ALGOL60 derived language, was designed, but actually never implemented.

The assignments of Software tasks to the development teams of Bull and Medium System Department in Phoenix were made: Bull abandoned for some years any work on COBOL, while some competence in basic operating system was attributed to what was then a very inexperienced Bull team.

 An ACT team, under the responsibility of MIKE BAILEY, reviewed the results of the preliminary software studies. That report was essentially confirming the initial design decisions about the use of segmentation, condemning demand paging in the sake of performances, recommending however paging as a tool for memory chunks allocation. It was insisting on the use of a powerful Macro-generator, both as a software methodology tool and as a job control language extension. It also let Management unwary about the "subsettability" of the interior decor, assuming that segmentation mechanism could be specific to a hardware model, without impacting the software unicity.
It might have been that ACT was hunting from contracts in several GE divisions!

Architecture approaches

That period was marked by a cross-culture exchange in the software area between the GE600 world, the S/360 influence on Bull designers and the Burroughs culture that predominated in ASTO. The role of ASTO's Jack MERNER, one of the key architects of the Burroughs B5000, and that of Mauro PACELLI, head of sofware ASTO unit, should be specifically mentioned.

The Bull initial interior decor was then complemented by the implementation of a stack mechanism handled by firmware for parameters passing, while the arithmetics remain in S/360-like registers.

The general conventions of a static linkage mechanism were established. The introduction of the "process" concept in the interior decor was confirmed, although many designers from GECOS3 and MULTICS were very reluctant to freeze the software design of those architecture elements. [Note that L178 Processes are called threads in recent Operating systems terminology.]

The concept of Process group and its identification as job steps' occurrences were introduced during that period. A process group could be a multi-threaded iser job step, a subsystem or a multi-threaded server. Most of user applications were to remain single thread process groups.

A "Smart indexing", i.e., indexing modulo a length dependent upon the operand type was introduced.

Retrospectively, it appears that too much importance was given to the ease of implementation of some languages' features by compilers at the expense of CPU performances for high-end machines. It was assumed that all the machines would be micro-programmed (in PROM), a difference with the S/360 decor where the assumption was that the majority of instructions. should be hard wired-on in  the upper end processor.

A use of  ASCII code was planned at that time because IBM was then to have an ASCII mode on S/360 and because the overall culture of GE Computer Division was extremely reluctant to target any kind of IBM compatibility, such as the EBCDIC encoding , that was selected later.

Technology

Two Technologies were considered : a SUHL Sylvania technology as used in the GE655 and a CML (Current Mode Logic) technology developed in GE laboratories. Eventually, the CML was chosen as the base of the study, probably due to an intense lobbying of research people in front of John Haanstra, a  manager who remained technically minded.

Although the level of integration of CML was at that time extremely embryonic, that technology was chosen for its performances and its low power consumption (relatively to off the shelf ECL's) .

The main memory was assumed initially to be magnetic core in spite of its labor intensive cost figures ; at that time, GE was planning to set up a core weaving factory ...in the Navajo reservation! You should note that the intended manufacturing cost ("shop cost") of a 32-bits CPU  was planned to be 8,900 1970-dollars, while memory's cost was expected to be 8,000 dollars per 32K Bytes!

The R370 CPU was to be developed in Paris - under the direction of Jacques BIENVENU ; it had to be based on hardware blocks, planned to be common to all the components of L-178, called SOMA (System Oriented Macro Assembly). Those SOMA were envisioned to be eventually LSIfied in a future version

I/O Subsystems

The peripheral controllers of the main line were to be developed on a common design of the Bull URC, while E120 peripherals had to be "integrated" and controlled by the CPU firmware..

The overall architecture of the PSI Channel --Peripheral Subsystem Interface,  was drafted at that time.

Because the 8-bit byte orientation of the L-178, the PSI had to be a parallel 8-bit channel. For data integrity reasons, due to the relatively low reliability of the subsystems of that time, it was excluded that PCPs had a direct access (DMA) to the main memory and decided that those accesses had to be controlled by the CPU itself.

A separate IOC (input-output controller), regrouping the channels' access to the system memory, was not envisioned at that time for cost reasons. It was also considered that the PSI should be the "long" cables in the system because the interface between the PCP and the devices might have to be specific and ought to control a "real-time" interface. This general design was later adopted for both the new product line and the GE-600+ line. In the latter, PSI channels -- although never actually identical to the NPL ones, supersede progressively the old (1965) Common Peripheral Interface (CPI) 6-bits wide channels.

It may be interesting to note that the main Discs that were contemplated at that time were removable discs with a 17MBytes(!) capacity and a transfer rate of 468KB/s. Future (1975) discs with up to 300MBytes were envisioned.

The L-178 systems remained punched card oriented.  GE was assuming a development of optical- reading of documents that was never materialized. Impact printers had, at that time, already reached their maturity (at 1300lpm).

Reliability

The expected reliability was poor in face of present standards, no more than a MTBF of 100 hours. That was due to the low level of integration of the technology and consequently to the amount of connectors and cards existing in the system. It was expected to spend a large amount of hardware to check the system data integrity and to insert control probes.

End of L-178

At the end of 1968, the results were not satisfactory in the technology and hardware design areas: the building blocks (SOMA) were too numerous and the CML was not ready to be used by the 1970 time frame.

John HAANSTRA was asked to take direct responsibility of Phoenix engineering to reorganize the GE655 project --alias GE6000--, and Gene WHITE left the company.

Bull-GE reconsidered the R530 project in a more conventional TTL technology as a System730/30 and the Italian acted similarly.

Phoenix MSD -Medium Systems Department- was disbanded and merged with LISD (the GE600 engineering group).

1969

It should be reminded that 1969 saw the first abandon of a computer manufacturer company: RCA retreated and sold its business to UNIVAC.

July-October 1969

Shangri-La

To set such a plan, R.BLOCH assembled at Hollywood-by-the-Sea, near Fort Lauderdale Florida, during the summer of 1969, a large set of specialists from all the branches of the Company including from the Corporate Lab of Schenectady- with Robin KERR from the software department, and from the MULTICS lab with André BENSOUSSAN on loan from Bull.

Bull sent Planning people such as Michel JALABERT , Raymond CHAUVEAU , Bruno LECLERC etc....Engineers were selected from departments not presently involved in NPL such as Claude BOUVIER the chief architect of GE51 and obviously some of the architects working on "NPL" such as Georges LEPICARD in hardware, Jean BELLEC and Claude CARRE in software. GEISI had notoriously Marisa BELLISARIO and also Paolo CESA BIANCHI, Mario ROSSI and other engineers.

The "main team" of around 50 people stayed assembled from July 1 to the end of October, while numerous people were called to feed in information, such as Marc BOURIN for technology and the Bull hardware and software designers involved in the previous steps of the project.
Managers from GE and subsidiaries --J.P. BRULE who joined Bull GE around this time, Tom VANDERSLICE who was then Peripheral division manager - also attended the meeting for a few days. John HAANSTRA died in his private airplane crash when coming back to Phoenix from Florida.

The fall-outs of this meetings were many: but, above all, there was a cross-culture confrontation that was extended to market analysis and planning.

The objectives were to increase significantly the GE market share and to provide a homogeneous offering on almost all market segments. Marketing studies mapped very closely computers' size and customer's size and the major bases for market analysis were "migration tables" based on existing systems and customer loyalty estimation. Vertical segmentation was essentially ignored and software inertia was underestimated. Professional market analysts as J. Diebold or IDC had not yet appeared at that time and the computer manufacturers had to rely on in-house analysis.

The disappearance of punched cards for data entry was now expected, but key-to-tape off-line systems were expected to compete successfully against on-line data entry.

Disc based operating system was expected for all members of the line.

Some of the main technical detailed decisions that have been taken during that period, were to use a Semaphore mechanism for process synchronization and to give priority to the segmentation of the address space instead of paging a single address space if the hardware was not able to get both economically.

As software products, the experience in the, then emerging, Codasyl Data Base organization based on GE IDS was brought by Charlie BACHMAN into the technical culture; the importance of database journalization and roll-back was brought in by Russ McGHEE from the WEYCOS project --an early transactional system based on GCOS-II on GE-600 for the Weyerhauser Company.

Shangri-La Output

The formal output of the Shangri-La meeting was a Master Project Plan that called for a new Advanced Product Line (APL) with four models:

• A-model was to be a very small business computer,
• B-model was essentially what the Italian had defined
• Bull and Phoenix had to plan for two fully compatible models the D-model (Bull) and the E- model.

There was no technical C-model because GEISI had "demonstrated" that the related market could be handled by the same technical object as "B".

An important output of the Shangri-La meeting was the importance given to the problems of park conversion, both internal and external.

The Emulators that were taken in consideration by the meeting had been:

• the GE100 for which the "C" and "D" systems were targeted,
• the GE58 for which the "B" was shooting, although some Bull designers did not desperate to have the GE58 being born again as the "A" system
• the IBM360/20 that was correctly seen as an orphan in the S/360 lineage. Object code compatibility with IBM 360 was not technically taken in consideration.

On the contrary, it was envisioned that Plug Compatible Manufacturers (PCM) could target APL for peripherals or memory units and measures were considered to counteract their entrance on the APL products both in hardware, in software and in maintenance. Channel compatibility and device interface compatibility were excluded that reason. Later, Honeywell experience made the engineers changing -- somewhat- their mind at this subject.

Weaknesses of the Plan

No Manufacturing plan was actually established. An unwritten assumption was that each country would manufacture the systems they design, while some double- sourcing was envisioned.

The Shangri-La meeting was not very fruitful in the domains of technology: GE had expressed that they would buy it instead of making it and participants had extremely erroneous forecasts when they did not predict the advent of semi-conductor memories. Shop costs computed at that time showed to be accurate a few years later, but memory sizes were widely underestimated and led to some errors in software future design. The meeting also underestimated the importance of transaction processing and completely failed to predict the advent of personal computers.

The evolution toward distribution in departmental systems, and multi-vendors' systems was not identified at that time as part of the market requirements. The identified sources of business were the replacement of existing systems and new applications. The important revolution what was emerging i.e., the evolution from batch processing to on-line processing was not given enough attention especially in the low-end.

1970

Shangri-La Follow-on

The main cause of inefficiency during the meeting was due to the parochialism of the participants which was generally encouraged by their hierarchical management because it was assumed that manufacturing was the major source of profitability and that it had to be closely located near the engineering.

It was understood that R.BLOCH intended to build a new engineering organization in a new location, i.e., BRIDGEPORT Conn. and that selected participants will have to move there and some will have to expatriate. As almost all participants did not intend to start from scratch their professional --and sometimes personal life, so there was a considerable reluctance to follow a person who never imposed himself as a charismatic leader.

Just after Shangri-La, Bull reorganized its engineering to be able to take a strong position in the incoming bargaining.

• Marc BOURIN  took over both Engineering and Planning for the future Medium Systems machine, replacing Pierre DAVOUS
• Thierry CHAIN took responsibility of Software, replacing Jean Paul BOSS.
• Hardware Development was then split between Christian JOLY for technology and implementation
• and Georges LEPICARD for system design.
• André RIVIERE was named in charge of Marketing and Planning.
• Product Planning itself was under the responsibility of Jean-Philippe BECKER assisted by Jacqueline VIDAL, and Lucien NEGRE.

During the period of November 1969 to April 1970, each organization was continuing work on its own part of the project. A relatively weak coordination was held in Bridgeport under the authority of Robin KERR for interior decor and software and Al CONOVER for hardware and product planning.

A commonalty with IBM S/360 I/O at channel- program software level was studied at that time to evaluate an S/360 emulation. The general specification of the PSI channel was specified and particularly its radial configuration as opposed to the multi-drop IBM channel.

Bull performed an analysis of a paging architecture in measuring the sensibility of the operation of IBM OS/MVT running under CP67 on the Grenoble University 360/67. It should be remembered that main memories were still extremely small and that it was requested to operate a full functionality operating system on 64KB, and there was even a proposal to run such an OS -- with paging, into a 4KB memory for the low-end "A" system!

May 1970

Honeywell takes over

General Electric withdraws from the Computer Market.

GE Corporate Planners and Finance people examined the results of the Shangri-La meeting that were presented by R.BLOCH as an "implement or die" gambit. The finances of GE were drained out by other technology oriented projects that were nuclear energy plants and airplane engines. So GE Management decided to go out of the business and to look for a buyer. They finally decided to sell this business to Honeywell.

Honeywell was faced to a similar need for growth and had R&D cost problems. Honeywell Boston designers, during the same summer, had meetings similar to Shangri-La in Cape Cod, but in a less grandiose show. However, Honeywell killed their internal ACS (Advanced Computer System) project, essentially for technical reasons. ACS was an object-oriented machine, the performances of that being not able to compete against more conventional computers.

Honeywell decided eventually to buy the General Electric computer business that brought to the venture a strong distribution network in Europe especially in France and in Italy as well as uncommitted engineering development forces in several countries. Honeywell was then proud to post billboards calling out "The Other Computer Company".

July 1970

Honeywell assessment of APL

Honeywell was impressed by the output of Shangri- La on the points of business planning and technical matters. It decided to look at the GE APL project with an extreme interest.

In BULL, in July 1970 a small team of 4 people -- André BENSOUSSAN, Axel KVILEKVAL, Claude CARRE and Jean BELLEC, was assembled during 6 weeks to draft an "Overview of APL Operating System" that describes the main options of what later became GCOS64. A decision was made at this time to use segmentation as a Virtual memory management tool, while its role as a container of "objects" was precised. It was decided to separate the universe of the files --the "file system", accessed through data management, from the universe of computation: MULTICS was then in the process to add Data Management to its initial "single view" of the universe. The decision to implement the majority of the functions as Procedure calls services (à la MULTICS) versus the operation of those functions under servers (monitors), with the natural exceptions of functionally asynchronous operations like scheduler, input reader, output writer... was taken at this time.

Starting from summer 1970, Honeywell intended to regroup the engineering forces of its units in BOSTON and the acquired General Electric engineering to build a new product line able to succeed to the then aging H2000 product line as well as to replace the GE100 and GE400 lines.

The role of GE6000 was not yet fully assessed, because the Sales network of GE was significantly weaker than that of Honeywell in the US; the only significant inroad of GE-600 was GE miscellaneous engineering departments and BULL-GE had suspended the marketing of that system in 1967 waiting for a fix of engineering troubles that plagued it in the 1966-1970 period. In fact, what happens after the merger was that an aggressive sales network with only the GE6000 to sell was able to deeply root this system in the market in less time that Engineering was able to bring up a new line of computers!

The NPL Organization

Honeywell decided not to break out its own and ex-GE organizations, at the exception of its own minicomputer organization -- coming from the CCC acquisition that produced a line of 16-bit minicomputers, the best known is the H-316- in FRAMINGHAM, MA which was disbanded end of 1970. People had to move to BILLERICA Mass. to be incorporated in NPL development teams.

However, for NPL, some Phoenix engineers and noticeably Charlie BACHMAN, Pete DRESSEN, Bill FRINK and Ross PARK moved to Boston to work on NPL, in relation with the French.

 RF ANDERSON took the following decisions under the authority of Clancy SPANGLE, at that time Honeywell CEO:

• HONEYWELL Information Systems Italia was given the charge of developing the "Level 1" of NPL,
  
• HONEYWELL-BULL of France was given in conjunction with HONEYWELL Boston the responsibility of developing a "Level 2",
• Some future work was expected to be given to the Phoenix operation to develop a "Level 3", if and when the H6000 line had taken off successfully.
• Honeywell units in UK were to participate to some work as a subcontractor essentially on Level1.

The NPL had also important consequences in Japan

Engineering Organization

Honeywell started to have an investigation mission to dig into the newly acquired engineering forces. Among the reviewers were RF.Anderson assigned as NPL Program overseer, W.PODUSKA and mainly Ugo GAGLIARDI from Harvard Computer Lab who was assigned as the Technical Director of NPL Project. Ugo was given a small team of consultants as the NPL Technical Office in Billerica. Giuliano RAVIOLA moved from Pregnana as a general secretary of the project.

As it might be observed, the Italian component was subject to temptations of independence because its assignment to the lower end, and the origin of the key people of the NPL Technical Office was then seen as a way to control this temptation.
Jacques BOUVARD was assigned to this committee from the then disbanded minicomputer operation. His knowledge of French language may also have contributed to his selection.
Irma WYMAN represented the relationship with the old Honeywell establishment and particularly its Marketing Arm.
Doris BENCZYK was especially in charge of manufacturing.
In addition, some bright computer scientists, as Jeff BUZEN, known in the area of performance simulation, and Robert GOLDBERG, in the area of Operating systems, joined the Technical Office.

Jacques BOUVARD and Charlie BACHMAN made a lot of work to provide a formal description of operating systems functions using Charlie's data structure diagrams methodology. Difficulties for using it came from the fact that the methodology was not fully assessed for procedural objects and from the differences in "philosophy" between Jacques' view of an event-driven operating system and what was being designed in development houses.

Manufacturing

In parallel, an integration of Product Planning and Business Planning operations took place and common accounting and costing procedures were established. However, there was really no attempt to separate Manufacturing operations from their geographical management.

At that time, the following plants were in operation:

• ANGERS manufacturing GE58 and converting from GE400 to H2000 --a disputable move, Angers was significantly underloaded in 1971 and was producing the GE58 small business system.
• BELFORT was manufacturing essentially I51printers for G100 and G58 as well as card equipments for all the company. While the 300-cpm cardpunch of Cie des Machines BULL design was still in production, the Honeywell BOSTON know-how and the manufacturing responsibility for Honeywell card readers was being transferred to BELFORT.
• LAWRENCE (MA) plant was Honeywell prime source for peripherals (discs)
• HEPPENHEIM (Western Germany) plant from Honeywell was manufacturing discs, as a second source
• PREGNANA was manufacturing the G100 in conjunction with CALUSO.
• The British plant of HEMEL-HEMPSTEAD was devoted to H316 minicomputers.
• PHOENIX was terminating the GE400product line and was shipping a few GE600/6000.
• OKLAHOMA was building discs for GE and was being consolidated with Honeywell productions. This plant and the Heppenheim one were later (1975) transferred to Control Data Magnetic Peripherals Division (MPI) along with the retreating of Honeywell from that peripheral business.
• Several plants were located in the BOSTON area:
  • BILLERICA was becoming essentially the engineering plant.
  • BRIGHTON was the primary plant for H-200 manufacturing.
  • The minicomputers' plant in Framingham was closing down.

1971

Mode of Operation

The organization of the Technical Office was such that the effective design responsibility belonged to the Development organizations and that the Technical Office had a role of reviewer and of Project management. Technical meetings were held for 3 to 4 days each 2 months in different locations. The technical meetings were reviewing almost all-current projects and set up a list of Action Items the accomplishment of that was reviewed at the next Technical Meeting. The meetings were held in different locations to allow more "local" presenters from the host organization. Meetings took place in Billerica, Paris, Pregnana, Phoenix and even Tokyo.

After a few months, Ugo GAGLIARDI was also promoted as a manager for the Boston operation while retaining his responsibility as a NPL Technical director. he remained perfectly "objective" and sometimes was obliged to forget the interest of his "parish" in the conflicts between Paris and Boston interests.

The "Level 2" responsibility was split between Paris Medium System Department, under the authority of Marc BOURIN and Boston Medium System Department where operations were located in Billerica for Management and hardware design and in Waltham for software development.

Software was assigned on the following way: Two nuclei were envisioned:

• level 2B for 'large systems' optimized around 512KB main memory size,
• level 2A for 'small systems' around 128KB.

The same extended machine specifications were planned for both nuclei and the same applications and software tools were planned for both 2A and 2B levels.

Paris was to be responsible for the small nucleus and for linker and loader components. Boston was responsible for the large nucleus, for the software factory and for COBOL compiler as well as for "advanced" access methods like UFAS Unified File Access System ( essentially a clone of IBM VSAM KSDS organization) and IDS (Integrated Data Store).

Level 2 Software

After some time, the large nucleus design was discontinued and all the OS responsibility was assigned to Paris.

Along the US key contributors of this period where GCOS64 really was born, we should   mention the role of Charlie BACHMAN. He was working in the Data Management architecture with Pete DRESSEN on IDS and Dennis WARD on UFAS design. Paul DERBY was the responsible for Utilities and End User facilities --the name used at that time for what became L4G later--

In Paris, the nucleus design started under the responsibility of Claude CARRE and included the finalization of the Virtual Memory Management, of Physical I/O and of Exception Handling.

Alain POUBLAN was, in liaison with the US, succeeding to design a file organization providing a large level of independence between the program view, the access methods and the stored file format. It was decided to provide several file organizations especially for conversion purpose (sequential and indexed-sequential à la IBM, H-200 formats), and a unique system access method, named "queued sequential" was adopted. This method was allowing dynamic storage allocation and was expected to be used also for message queues-- that were later implemented through another mechanism.

Job Control Language was to be extended to several properties of a language. It was later "simplified" to mimic GCOS3 functionalities and later extended again in 1979 GCL. It was to be preprocessed before its execution by a general purpose Macro-generator that was able to recursively operate on characters' strings. This implementation made by Claude PENDZEL and Richard RAPAPORT had proven flexible but CPU time consuming and was replaced by a more conventional processor by 1976.

The coordination for software was made by a Software Technical Coordination Committee, meeting alternatively in Paris and Boston every month under the control of a Software Management Review Committee (SMRC) meeting each two months also alternatively on both sides of the Atlantic. Thierry CHAIN, Jean BELLEC and Jacques BERNADAT --Bull software program manager, represented Bull at SMRC while Dick HILL -- hired from Informatics --, and Dick ANGEL , represented Honeywell. Problems during this period were the frequency of the meetings (10 transatlantic flights per year for the responsible people) and the imprecision of the relative roles of the local management and of the NPL technical office.

Hardware

In Hardware, the separation of the work was the following: Paris was to develop the P7 CPU while Boston developed the P8. Both systems were to be built of TTL74N technology and use semiconductor memory.

While pre-production models of memory were 1Kbit based, production models were initially 1Kbit and then 4Kbits for France manufactured systems, while Boston planned and actually ordered specially produced 2Kbits chips, by lack of confidence in the technology progresses. It should reminded that in 1971, the computer industry was still the main customer of the pioneering semiconductor companies, such as Texas Instruments, Fairchild or Sylvania. It      had to wait until 1973 to see the watch and the calculator business taking over this primary role.

Honeywell management was extremely surprised by the NEC policy of entering the semiconductor business in the frame of  a "VLSI cooperative project" set up by the MITI. Honeywell considered that NEC policy too technically oriented --what is true --, and that the decision to build VLSI was contrary to the trend of the business --what remains to be proven--.

The Printed-circuit Boards technology was named SP-10 with relatively small board size and was still manufactured in 1987 for tape controllers.

In the Manufacturing and Order processing area, a new set of nomenclature for NPL products was established (marketing identifiers --MI-, IPI and parts numbers...). This was applied to all NPL members including the new versions of GE6000 (Level 66) and of GE58 (Level 61). This system was still in use in 1990.

Finally the Interior Decor was finalized. Honeywell Bull was assigned the "control" part of it, while Honeywell in Boston was finalizing the "user" part of the decor. The first part was more subject to the influence of OS designers while the second one was more sensible to compiler designers' requests. Among the designers of the "control" part, it is desirable to name Marc APPELL, Philippe de RIVET, Pierre SEVRAY and Jean Claude CASSONNET.

Among the issues that were debated during this period, one was the fairness of the choice of EBCDIC 8bit byte in place of 36 bits words of the GE6000. It was argued that 9bit bytes were able to support both EBCDIC and ASCII characters (!!!) and that IBM will move soon to a 9bit byte (referencing their tape format).

Another issue where a choice may have proven incorrect was the selection of the IBM CKD format for discs. It was incorrectly believed that the discs controllers could relieve the CPU from "search on key" operations and lead to a better overall performance of the system. It was incorrectly assumed that one controller per disc drive was quite close to emerge. It was also planned to have a media interchange at discpack level with IBM, and that has been actually implemented for the 2314 DOS format. That external specification, obviously, lead to the choice of a CKD format.
Furthermore, the MSC designers "improved" the IBM format in the direction of more sophistication like the multi-track operations and the "SEARCH on DATA "operation that, happily, was never used by the software.
Anyway, both Level1 and Level2 went to CKD and were not able  to completely get rid of it.
The choice of the IBM VTOC format, however, allowed Level 2 to get a more reliable interchangeable media support than  GCOS3 or MULTICS had . That peculiarity was extremely precious in the debugging of software on several systems.

During this period, Marketing was complaining about the wasting of memory that was the consequence of a new operating system. Marketing was still requesting a 64K system at a time where it was only possible to have a GCOS64 --the eventual name of NPL OS Level2, running in 256KB! A kludge solution of "hidden memory" was invented in 1974 to let the customer believing that he had only the sold 64K(and delivered 512K)!

The initial target of the NPL OS was directed toward a batch environment like its predecessors H2000 and GE100. The data communications applications architecture was still really fuzzy. Boston responsibles were sticking to the specifications of the proposed CTG COBOL standard were ignoring either the emerging existence of networks or the use of anything but a single COBOL programmed set of applications per system was envisioned. All responsibility for DC was under the CTG application programmer who sometimes was surprised by the response time of the RECEIVE/SORT/SEND sequence!

Time sharing applications à la MULTICS or à la GCOS3 TSS had been ruled out by Marketing and Management. The Transactional environment was not yet planned but was considered as being an architectural constraint that set up multi-processes J (process-group) and the reserve of type-1 segments.

Program preparation was very classical. COBOL was to be the primary language for NPL. The compiler design in Boston was under the responsibility of Ron HAM, later in DEC and then the chairman of ANSI Programming Languages Committee.

PL/1 was being de- emphasized and it was decided not to target the implementation of its relatively exotic facilities such as dynamic tasking (the future FORKing) nor to optimize on its dynamic type conversions. In fact, some interior decor features, like typed data descriptors, had such a support in mind. But, when compilers did not take advantage of them and because their performance cost in firmware, they were abandoned before being put in use.

It was also initially planned to provide early a "Descriptor access method" to provide data type independence between programs and the contents of files. But, this sub-schema implementation was so delayed --until late 1980s, that the initial work on that was practically scrapped. The definition of the language processors and of their run-time environment was dominated by the need for adherence to standards that causes many controversies in the area of CALL/CANCEL verbs: did the compliance to standards imply dynamic linkage of procedures? Honeywell had, at this time, several standards gurus in its organization and the gurus' answer was finally negative: static linker could comply with the standard.

After resolving those controversies, the end result was finally that GCOS64 was able to present one compile-unit format common to all languages (Note, however, that BASIC and APL, nor obviously LISP were not contemplated at that time), that was something that IBM was unable to get in S/360-370 and that GCOS8 is still struggling to get close. A Linker able to process those compile-units even in a multi-thread ( process)  environment was designed by Claude MASSUARD and is still in use to day, although its design was one of the major issue raised  in Paris in 1972-1973. The number of segments was already considered as a scarce resource and a "binder" capable to merge several compile units in one segment was designed in Boston essentially to maintain the operating system modularity while economizing the number of segments. The Loader, designed by Xavier STEFANI, had the primary responsibility to link the pre-linked load modules with the operating systems entry points and to allocate virtual memory addresses to the segments of the program.

The design and the development of NPL Level2 software started initially using MULTICS and a simulator operating -- very slowly, on Boston MULTICS initially. The first original prototype was available on April 1st, 1972 and a primitive, memory resident, operating system, the SCP, was almost ready to be tested on it.

1972

The P7 Prototype

The initial prototype was built in Paris with parts manufactured in Angers and in Saint-Ouen. It was installed in salle MAP at Gambetta. It consisted into a CPU, a 128KB magnetic core memory --which was later replaced by a 1Kb semiconductor storage, a Unit Record Processor with a card reader, a PR71 line printer and a Terminet TTY like console. The service processor functions to be handled by the URC were not yet available and LED panels and switches had to be used for kernel and firmware debugging. The responsible persons for the CPU developments were Georges LEPICARD and Jacques BIENVENU. The responsible persons for the URC were Henri VERDIER and Gerard De PONCINS.

The debugging on actual hardware needed synchronized updates of the Assembler made by Boston team and a daily shipping of a card pack from Boston where the compile/ link/ load process took place to Paris where the prototype was being debugged. Surprisingly, this distributed effort lead to one batch run per day, complemented by firmware and software patches, which was very closed to then prevailing standard for software debugging. A back-up assembly was also being made on the GE635 factory and management required that simultaneous updates of both factories and program libraries be maintained. By the end of June, at the price of an enormous amount of over time, particularly by Jean Paul MESNAGE the responsible of SCP, this basic operating system was debugged and the prototypes could be operated by T&D development people, peripheral controllers connection and software development.

Additional prototypes were built: one was shipped to Billerica to complement the debugging of tape and disc controllers that have been preliminary debugged on a PSI simulator. A prototype was also shipped to NEC, but this one did never reached Japan: it was burnt in a 747 sabotage in Benghasi in July 1973.

The bootstrapping of the initial parts of GCOS64 nucleus was made from the SCP that operated as a loader and debugging tool for the different modules of the system.

A similar approach was taken for the development and the debugging of the G100 emulator, but for GE645 capacity reasons as well as for some hereabove noted parochial reasons, the development was made on the GE635 factory. The H200 emulator was developed in Boston, under the efficient management of the late Maria WELLER and used more extensively the GE645 factory. It started also from the SCP and later switched to another Boston environment (see hereunder).

The Performances measurements started without to many tools: a hardware monitor was included only in 1973. The "measure" used for system comparisons at that time was "Business Gibson Mix" a computation of instructions times oriented on character strings and similar to the scientific Gibson Mix then in use in the industry Software overhead was ignored as was ignored the efficiency of the compilers. HPL language performances were not very satisfactory and the decision to code the nucleus in Assembler appeared to be a reasonable decision considering the time needed to get good performances from HLL compilers. Later, performances measurements tools initially designed by Phoenix were introduced in NPL, especially PCMix that included software compilers and run- time efficiency.

The Specifications of NPL Level2 were challenged from two sides: Product Planning people, especially in Paris, found that it was too ambitious for a G100 batch replacement and that it should be closer to DOS/VS than to try to match OS/VS or some MULTICS functionalities. A proposal was made at that time in Paris to drop the development in favor of what was still a paper OS, named SSS, planned to be developed from SCP by the G100 emulator team. On the other side, and especially in Boston, it was argued that the software was not ambitious enough in terms of dynamic resources management and that it had been erroneous to drop the level 2B nucleus at the profit of Paris design

The Paris team had also to face a tremendous staffing problem: in 1972, all software available persons have been put on board of GCOS64. A frantic hiring of new people was made to increase the number of developers from around 50 to more than 180. Almost no turn-around of personal was noticeable during this period. However, difficulties of the working conditions (a high overtime --up to a week of 60 hours, the lack of GE645 time, of prototype time caused some social unrest at that time.

1973

The Difficulties of 1973

The difficulties of the development lead to a management crisis at the end of 1972. It was seen unlikely that NPL Level2 was able to reach the market at the end of 1973 as originally planned by Upper Management --less than 3 years of design and development. Jean BELLEC was replaced by Claude CARRE as the responsible for development in Paris. The software organization of Hardware engineering was merged into the Software development organization. At the same period (early 1973), Georges LEPICARD who has been one of the key architect of the NPL left the company to head the scientific direction of CII. He will return in 1976 after the merger between Honeywell Bull and CII to lead the "Leo" project that was marketed as DPS-7/80.

The 4A Back-up

A contingency secret plan for a Back-up was established in Boston; it was unveiled only in its support of H200 emulator. This project named as 4A Back-up was managed by William HEFFNER an original GCOS3 designer, who later left to DEC to become VMS manager.

This OS differed from Bull Level 2 design by a more interactive operation: one process per "user" and by a simpler and less effective virtual memory management: let the space per user increase and flush the address space in case of overflow conflicts. This system used the same compilers as Level2 and the "competition" period had an 8 months' duration.

End of P8 Project

Ugo GAGLIARDI, by April 73, had to step down from direct Boston (BCO) responsibilities which were taken by Walker DIX who then cumulated the engineering responsibility of Phoenix --then being reborn of its ashes, and of Billerica.

The P8 Project was cancelled, at the best pleasure of Paris hardware designers. In fact, P8 did not show enough performance advantages from P7 from which it differs not by technology, nor by the word length, but only by a cache memory and better scientific performances. That machine did not implement multi-processor, although this was initially contemplated.

The NPL Technical Office was dispossessed from program management responsibilities and assigned to the technical cooperation between the HISI project (level 62), the Bull Level 64 project and the Phoenix Level 66 development.

John WEILL head of the Research Center was given the responsibility of the overall project coordination and he appointed William FRINK to insure Level 64 software coordination. Ernie DIETERICH, with Michel ROCHER as an assistant, was later assigned to Paris to manage the GCOS-64 plans.

1974

The Series 60 Computational Theater.

The NPL Technical Office was then involved in a frantic search of a common image to be given to the then planned Series60 computers that would cover in a single announcement:

• the Level 61 system --a Bull low end product, essentially a re-announcement of GE58,
• the Level 62 system developed by HIS Italia as the low-end of NPL,
• the Level 64system --alias level2,
• the Level 66 system which was essentially a re-announcement of the H6000 system.

A lot of work was spent in task forces to try to achieve a common external visibility in terms of programming languages, data bases organization, job control language and operator interfaces. It was actually a task analogous to IBM SAA 15 years later.

Formidable obstacles reside in the architecture differences between Level 66 with its 36-bit data types --with 6-bit and 9-bit characters, as well as ASCII characters - present in Level 61 and 66- versus EBCDIC in Level 62 and Level 64. Some "compromises" were made by Level 64 to be closer to Level 66, in particular on JCL and cataloging mechanisms.

The specifications of the, then emerging Level 64 TDS were accepting the then current specs of Level 66 TDS and emerging DMIV-TP, sometimes at some expense of functionalities.

Although the Level 64 was considered as a better vehicle for the out of base market, software functionalities lagged significantly behind IBM's or Level 66. Also, some intense lobbying occurred to demonstrate that IBM was just to scrap 370 at the profit of the "FS", and that, consequently, the level 64 was likely to compete with 370 at the time it would become obsolete.

An attempt to have a common assembly language between Level 62 and Level 64 failed on the differences in Operating system calls. Italians who had a target of Level 61 takeover, were not accepting the unification on the UFAS basis and developed their own data organization which was a superset of IBM System 3 and of Level 61 including an ESDS organization and chains of "complementary records". This organization was later introduced in GCOS 64 as MLDS.

Those efforts were developed under the name of "computational theater", a name coined by John WEILL who played an important role in this period. The majority of the technical energy was spent to "give a common image" and to facilitate migration whereas it was sure that the requirements for coexistence were very few at a time where distributed systems and communication networks were still in their infancy. Nobody, however, in any organization was thinking seriously about moving a customer from a Level to another one: each parish actually planned to move up with its lot of customers.

The coordination made by the NPL technical Office, and particularly by Gerald CLANCY and Ugo GAGLIARDI was not involved in the decision process of the implementation shops and was unable to make approved anything but "common subsets" of the different implementations. The laxity of "industry standards" including ISO and ANSI standards authorized many "implementer defined" features in conjunction with contradictory "default" options. A lot of energy was spent defining "common default" options in COBOL, FORTRAN and RPG. From this experience, it should be remember that a computation theater cannot be based on existing applications when those applications take benefit of machine specific features, such as physical representation of objects and of specific hardware or operating system features. It would be possible to specify common products portable on different environments at the condition that the initial ports be made by a single team.

A decision was made to merge Engineering operations of Phoenix and Boston under Walker DIX with the goal of increasing their synergy. Among the assets imported from NPL to H-6000 were the COBOL-74 compiler written in HPL and which was converted to GCOS-III via a PL/1 compiler.

1975

Some Honeywell management views, however, implied a phase- out of Level 64 at the profit of Level 66 as soon as the G100 and H2000 business sources would have dried up.

Consequences in Japan

It should be noted that the Honeywell takeover of GE operations was not without consequences in Japan. The TOSHIBA company had a long relationship with GE and was a licensee of GE600 and GE6000, while Nippon Electric (NEC) was a Honeywell licensee for H2000. The Japanese Ministry of Industry and Trade (MITI) pressed the two separate companies to work together and that lead to a progressive takeover of TOSHIBA computer (mainframes) operations by NEC.

Honeywell signed up with NEC a 10 years' know-how transfer agreement giving to NEC a full access to NPL. All NEC current mainframe products -- ACOS2, ACOS4, ACOS6 and later MS (Level 6) products  -- are born under this know-how agreement.

NEC acquired that know-how not only by buying documents but also by sending contributors in the Honeywell teams who were working on NPL as well as on H6000--the new name of GE6000-. For example, Y.UMEMURA was involved in H2000 to Level2 emulator and conversion team in Boston. Y.TSUJI, H.SHIN were staying for several years in Paris to work as programmers and later as coordinators of the know-how transfer. K.NISHIMURA was also involved in the manufacturing "dossier" technology transfer in Paris and Angers.

A conflict occurred around 1974  between NEC and Honeywell. NEC had actually decided to make Level 64 -- alias ACOS4, its primary product line. NEC seemed to have taken this position because Level 64 was locating itself in a 32-bits EBCDIC world which was the world of Japanese big customers and also because the old NEC establishment was very reluctant to unite with TOSHIBA designers who had worked for long with GE on the GE6000 product line. Those differences inside NEC vanish progressively because NEC management succeeded to have a common organization for ACOS4 and ACOS6 product lines with the only exception of the Basic Software Divisions. Nevertheless, Honeywell forced Bull to cancel a new hardware project the P7A, an ECL machine adding a paging architecture to the original 64, which was planned to be developed in Paris in common with NEC in 1973.

Honeywell put also a lot of pressure on NEC to involve it in a new GCOS66 project called the Med-6 project . NEC accepted to work on Med-6, and, for instance, Yoishi UMEMURA was transferred from Boston to Phoenix on this project. NEC invested later into the ill-fated Med-6 using CML and water-cooled technology that was announced by Honeywell as 66/85 and was later abandoned when it was  facing performance problems. This design was still imported in Japan without water-cooling and was the ACOS S/800, running under ACOS6. In the mean time, NEC did not abandon any of its developments on ACOS4 and even decided in the early 80s to let this product line overlapping completely the ACOS6 product line.

L66 and Multics

In 1972, it had been decided that the migration path out of the limited decor of the GE600 should be through the MULTICS decor that gave to the 36-bit world similar advanced functionalities as Level 64, for segment-level protection and high-level language support.

A coexistence through a GCOS3 accommodation mode under MULTICS, the development of a transaction system à la Level 64 TDS on MULTICS decor and the outstanding capabilities of MULTICS interactive facilities - given enough hardware power- would have made a more than reasonable product in 1974. It was also planned to implement a virtual machine project on this system that might have allow a future co- existence of a 32-bit world with a 36-bit world. It was also planned and eventually implemented to have a H2000 emulator on the Level 66, but this was provided by the reconnection of a used H2000 to the Level 66 system controller and did not imply access to the H2000 peripherals.

The work based on MULTICS decor was a little bit late - like the other NPL projects at the exception of Level 62- and W.DIX finally endorsed a proposal of John COULEUR, the original designer of GE600 and GE645 hardware, to introduce a new decor -called NSA as New Six thousand Architecture- instead of following the MULTICS roadmap. The new decor was considering segmentation as data set descriptors and introduced address space as the inter-user protection mechanism; the "ring" concept was dropped for a "domain" mechanism that potentially would avoid the "Trojan Horse" syndrome of user data violation of privacy by procedures planted in the system by some dishonest programmers; it also introduced a progress over NPL implementation: it offered a hardware controlled stack independent from software controlled stack to store registers and return information. This new decor was allegedly to be field retrofittable on existing systems, which was eventually found not feasible, and justified a delay to implement the new facilities. The decision was fought desperately by MULTICS supporters, but Marketing and Management were not clever enough to appreciate the consequences of that decision.

It is not here the purpose of telling the history of GCOS8, but it has to remember that it took 6 additional years to be introduced and that the unification of the segmented environments remains to be seen 14 years later.

Birth of NML future Level 6

At the end of 1973, Boston Computer Operations had been completely re-oriented toward a mini-computer project, called NML -as New Minicomputer Line- which gave birth to the Level 6, later DPS-6, products. It ought to be a competitor for DEC PDP-11 product and feature a processor on one card. Part of the BCO staff was disbanded: some move back to Phoenix and were there using their experience in NPL to make the GCOS8 project rolling out; other left to DEC where they were instrumental in the VAX/VMS project; the majority move to the Level 6 project specially in the area of compilers and utilities.