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: 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 Level66 with its 36-bit data types --with 6-bit and 9-bit characters, as well as ASCII characters - present in Level61 and 66- versus EBCDIC in Level62 and Level64. Some "compromises" were made by Level64 to be closer to Level66, in particular on JCL and cataloging mechanisms.

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

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

An attempt to have a common assembly language between Level62 and Level64 failed on the differences in Operating system calls. Italians who had a target of Level61 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 Level61 including an ESDS organization and chains of "complementary records". This organization was later introduced in GCOS64 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 .

follow-on