May 1970



















July 1970

  honeywell_logo.gif (2265 octets)

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".

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.

Ugo_Gagliardi.gif (6236 octets)
Ugo Gagliardi (now)

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.

Back

Next

64-DPS7 Product Line

Index

Révision : 19 février 2002.