Honeywell-Bull     CII-Honeywell-Bull     Bull

Operating System GCOS-64 GCOS-7




In this section, several aspects of GCOS covering features encountered within its development will be examined: 
 - the limits of the architecture that were originally suspected or that were discovered during years.
 - the constraints and decisions related to software engineering techniques in an industrial product.
 - the divergence (and their causes) with our original partner NEC.


Physical Memory

Level 64 architecture could address up to 256MB (28-bits byte address). As Level 64 hardware was limited to 1MB of physical memory by physical constraints (9000 chips on prototypes, 2250 chips on production model), the limit appeared reasonable and the extension to more than 256 MB might be designed without limited impact. The initial limit was 16 times that of S/360 designed 6 years before. The production Level 64 got RAM cards of 16KB. A memory size of 256KB meant one card cage of 16 cards and a fully configurated 1MB memory represented a complete cabinet (with electronics and power supply). Level-64-DPS were shipped in 1978 with memory chips of 16K bits, decreasing by a factor of 4 the size of the memory that was integrated in the CPU cabinet. P7G was delivered in 1982 with 64Kbits memory chips -the 64Kbits chips was the most difficult to pass by semiconductor manufacturers and the physical memory was extended to 2x4 MB.

Number of J

The limit of 256 job steps was relatively comfortable until many interactive users worked in the system. The limit was initially encountered by NEC that had made the choice to allocate a J per interactive user. They kept some J with up to 255 threads and while limiting the number of other limited to 16 threads. So, they succeed to have around 1000 J. Their design was adopted by Bull in 1986 but had a very little impact on GCOS.

Virtual Address Space

The address space both in terms of number of segments and size of individual segments appeared a significant restriction soon in the 1970s. Two "escape" mechanisms were implemented the large 4MB segments and the type 1 segments. In addition, the limited address space inherent to a 42 bits machine was one of the reason of the destruction of the address space at each step of a batch or an interactive job. Actually, systems like Multics were forced to rely on a "flushing" of the segment tables and a reconstruction of the dynamically linked space when limits were encountered. The decision of considering segments as buffers and not as part of the file system helped a little bit. It was also possible to segregate operating system functions as separate process spaces to increase the total address space.

Changes in that area were very difficult to make as other products lines had experimented. New software releases had to work on various "old" processors for customer convenience and to decrease maintenance costs. New hardware systems were introduced only at both ends of the product line.

For technical and "political" reasons, an extended architecture XSA was designed in the late 1980s jointly by Bull with NEC. When implemented, it would have allowed the removal of the constraints of the limited address space. However, only some parts, like extended physical memory space, were eventually implemented by Bull and NEC last processors were not marketed by Bull, nor the extensions made to GCOS.

Segment size

Most of the address space was available on segments limited to 64KB, not a strong limitation for procedure segments -forcing system and application programmers to modular components-, but for system tables that were limited to use less than 64KB. As tables might include several hundred bytes per item, that segment size was a limit frequently encountered. The way to go around those limits was to allocate a chain of segments or to undertake a more significant redesign regrouping several tables in a large segment as in non-segmented systems, taking care of non-introducing security flaws by that way.

Methodology, Integration and Delivery

The size of the project required an intensive work on integration and delivery methods. The architecture, per se, was not enough to maintain a good product. The development was divided into working groups producing system integration units, a collection of "debugged" (alpha-tested) source code, and documentation of a functional area.

Source code was originally coded, compiled and run in simulation mode under Multics on a GE-645. When Level 64 hardware became available, Multics role became more that of a repository of the source code. Flow charts, when used, had to stay off-line.
The situation was aggravated with the regrouping in 1975 of all the development in Paris and the integration of additional teams. A single 645 was not able to cope with programmers needs and a return to the old world of punched cards was undertook. 
Eventually, in the early 1980s PCs connected to a GCOS system became the standard equipment of programmers. Data entry, code corrections and documentation were made on PCs, while compilations and execution runs were processed under IOF on GCOS systems.

System calls, visible to applications or internal to the system were defined through HPL and/or MLP (and later C) macros. Those macros were expanded along with local programmer macros by a macro-generator pass before compilation. That procedure worked well as soon as all modifications were made in source form. However, the releases of the system were made on an yearly basis and corrections were required more often. If some corrections were done in source form and led to large amount of patches, frequently the correction was delivered only as binary (i.e. hex) patches and done also separately in the programmer source code for the next release.
Additionally, patches to correct a functional dysfunction were applied where it was the fastest to do, i.e. in areas where programmers had the time or the motivation to do it.
Consequently, the operating system became progressively more monolithic and minor changes more expensive to implement. Redesigns of large areas were the only way to clean the problem and to start on new bases.

The documentation of the customer operators and programmers was produced by technical writers from draft documents written in English by Bull programmers. That documentation was not always available for beta testing by Quality Assurance people. Beta testing was never officially at customer sites, although several products were introduced as "RPQ" for specific customers supported directly by Bull personnel. GCOS descriptions included flowcharts, table descriptions, and internal interfaces. Those documents were written by developers, edited by support people and distributed as microfiches to support in Field Engineering. 
Specs for duly commenting the source code were set up, but they were somewhat relaxed in the "punched card era" and the usage of English was also relaxed for French in some products developed by CII originated development teams and delivered in France. Anyway, all that technical documentation was only distributed internally and was not made available to customers. Those customers had to see the computer and its operating system as a "black box" running their application. That avoids dysfunctions created by an external usage of interfaces not documented as public (in programmer's manual), it also decrease attachment of programmers to their system and led to STARs (System Technical Anomaly Reports) not documented enough and mixed with improvement request. The situation improved in the late 1980s when customers and GCOS technical support got an under-siege mentality and collaborated in CUBE users commissions to insure their job's survival.


NEC ACOS systems

NEC acquired a full development license of GCOS as part of an agreement with Honeywell made in the 1960s and renewed in 1972. A few NEC engineers participate to GCOS 64 project as developers and the first ACOS4 release was almost identical to GCOS64. It differed only by a support of Japanese language, while their reference documentation stayed in English. NEC continued to have access to GCOS products in the 1970s, with the exception of HDSA products.

NEC used ACOS 4 on their high performance systems, including until 1985 where it was replaced by UNIX, on their supercomputer SX systems. They supported their own data communications systems and their own line of peripheral. They implemented paging, based on a 1974 common design with CHB, on their systems starting in 1980. 

NEC chose to design its interactive operation in a way inspired from IBM MVS. Networking adopted a mainframe centric architecture similar to SNA. Interactive processing was mapped on TSO architecture. Transaction processing was inspired from IMS/VS where a queuing server distributed transactions to specific servers organized by transaction type.

In 1985-1986, Bull renewed the cooperation with NEC, borrowing the design of the paging mechanism from them. However, both companies pursued their way on their software, exchanging presentations and ideas on innovative areas.


GCOS 64 and GCOS 7 were the successive names to the same continuous design. If other software systems showed a similar history, it is the only European software that had a comparable life: from old card batch oriented applications toward powerful transaction servers.

It suffered from the complexity introduced by the layers of functions introduced with time, from limits due to the high cost of hardware at the origin, from some dogmatisms in some areas that were circumvented more than corrected. GCOS was overall designed and managed for manufacturer-designed software. It respected industry de facto interfaces (i.e. IBM) more than other Honeywell and Bull systems but it ignored for a too long time the world of open systems.

It will survive some time to the abandon of its genuine hardware designs by being hosted in a SMP Intel architecture (initially IA-32, eventually IA-64), coexisting on the same enclosure with operating systems of other servers, serving the applications now becoming obsolete or not performing enough under GCOS in an open networking environment.

2001-2003 Jean Bellec