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.


 

Back

Next

Révision : 28 juin 2001.