Honeywell-Bull     CII-Honeywell-Bull     Bull

Operating System GCOS-64 GCOS-7



Cette page regroupe une description du Système d'Exploitation développé sous la direction de Bull pour les machines développées sous les noms Level-64, DPS-7 et DPS-7000 depuis le début des années 1970.





ilovegcos7.jpg (4974 bytes)
matériel publicitaire (bloc de post-it) distribué par Bull à une conférence marketing à Istanbul en 198x





The terms used hereunder have been "modernized" according the recent computer language, threads and micro-kernel were not an accepted terminology in the late 60s]
This page covers only a summary of GCOS7 software features. A more complete description is found in those links

GCOS 64 is a general-purpose operating system designed at the end of the 1960s for supporting Honeywell Series60 Level 64, a line of medium size computers, manufactured by the Compagnie Honeywell-Bull in France. NEC of Japan acquired the license and develops it under the name ACOS4.When the product line was renamed DPS-7 from Level 64 in 1981, GCOS64 was rechristened GCOS7 in 1981. Its kernel was substantially revamped in 1986 with the software release v3B that supports the new systems pagination.

Originally introduced for multi-programmed batch operation, many features allow it to support nicely interactive and transaction operation until the end of the 1990s and later.

A particular application running nicely under GCOS64 was the emulation of foreign machines running concurrently with native applications. Emulators were developed for GE-100, Honeywell H-200, IBM 360 and later for CII Siris3 and Siris8.Performance goals dictate often the architecture of an emulator. All emulators share the concept of a specific interpreter implemented in microcode (and consequently hardware specific) and of a native software support for performing I/O and getting support of the native operating system. H-200 (for flag delimiter recognition) and Siris8 (for op-code identification within the word) require also extra hardware.

During the early 90s, Bull ported UNIX on DPS-7000. That programmed named SPIX7 was implemented on a way similar to that of emulators, while UNIX operating system and its software was recompiled in DPS-7000 binary code and did not require an extra processor, while, in Artemis hardware, some DPS-7000 processors were sold  dedicated to UNIX applications.

Batch applications were made of jobs (originally initiated from the card reader), each job being made of sequential job steps. While resources (files, control variables) could be passed between steps (through the file system and the operating system), a new address space was allocated to each job step that was running as a process group in the processor. Typically, the programmer environment represented separate process groups for editing, compilation and linking…

Transitioning from batch to on-line interactive environment was accomplished by keeping the same architecture and replacing the batch control language interpreter with a new Interactive Operator Facility (IOF) with a separate process group for each user.
An interactive GCOS Command Language was designed, with menus and helps,  in conjunction with a powerful text editor. So that the main media for job entry became screen video terminals, the main operator console being a particular case of it.  Personal computers were used as IOF terminals emulating the VIP terminals.

The IOF design representing a relatively large amount of locked resources for each user, it was not considered reasonable to apply such an environment to thousands of users in a transaction environment. Additionally, transaction processing differs significantly from program debugging. Clerks generally perform transaction after the programs have been (somewhat) debugged. Additionally, transaction processing imply new programming concepts such as the notion of commitment, of dynamically shared data, of journalization of data that were absent from batch applications and of their programming languages. So, Bull designed a Transaction Driven System using the basic features present in the OS and the micro-kernel. TDS design evolved somewhat to overcome the limits encountered when supporting several thousands of users, but its basic features stay unchanged.
The ease of using TDS was constantly enhanced, starting with FORMS for plain screen terminals ( matching the IBM CICS competition), initially to satisfy the requirements of EDF and HCL customers. 

From the beginning , the choice has been made of writing most of the operating system in high level language, for readibility and maintenance purposes. The first version was very space  and time consuming, so that in 1975, a big recoding plan was undertaken, focusing on the most critical portions of the OS, specifically the chain of sequences for elementary I/O on disk. The result was a rather performing system, enabling GCOS64 to win several benchmarks against competition. 
Moreover, a  version of the HPL GCOS development language, renamed GPL,  was offerd to sophisticated customers (software houses, educated customers).

File system.

One of the initial requirements was that GCOS64 should be able to use the files (usually on tapes) created by the previous generation systems as well as IBM DOS/360 files. Those files were not cataloged and were handled manually, sometimes they were even not labeled. So GCOS64 had to be able to handle those removable files and support a modern file system. The permanent file system was optional, because marketing was afraid that its need might disturb the batch customer operation, creating the need for a centralized administration.

To ease the customer operation within those constraints, automatic volume recognition on tapes and discpacks was implemented from the very beginning.

The requirement to be able to access IBM discpacks and the heritage of past files lead to not adopting a uniform allocation on secondary storage and let the physical format (variable length for some tapes and for IBM ISAM index sequential discs) under the control of the file access method.

Operating system objects were stored and cataloged in libraries (a special type of file for the file system) where the library access method (called Queued Access method, because it included an append facility) performs the dynamic allocation of blocks.

The recommended organization for native files was the UFAS (Universal File Access System) used for index sequential files (inspired by IBM ISAM) and Codasyl networked files (IDS-II). UFAS files handling was improved in GCOS7 by adding a cache in (virtual) memory and a generalized access control allowing simultaneous access from separate threads (of the same or different process groups).

Volume mirroring was also added to GCOS7, with the capability of sharing files by threads operating in another GCOS system (at the price of using discs to store the locking information).

Cataloged files names had a length of 44 bytes that may be used as a hierarchical name, allowing access privileges to be regrouped in directories as in Multics. Import and export of cataloged files by transporting a discpack to/from another system was also provided.
The catalog included the support of "genarations" in closed and open loops. Note that the support of 'open loop' generations of files was implemented early at EDF customer demand. 

Programming languages.

The main implementation language of GCOS64/GCOS7 is HPL –Honeywell Programming language- (also known externally to customers as GPL –GCOS programming language -). HPL was a dialect of PL/1 where data types irrelevant for programming an operating system (such as floating point operations, heritage of data through threads, input-output statements …) had been removed. The language was extended through a macro-generator facility to declare system data (peculiarly the interface to the micro-kernel) and operating system calls.
The HPL compiler was initially implemented as SHPL on Multics 645. The macrogenerator was derived from TRAC.
To complement HPL to code of the nucleus, an assembler called NAL (NPL Assembly Language), using the same macro-generation facility and the same data types as HPL., was implemented.

The main customer programming language was and still is COBOL. The evolution of COBOL from Cobol68 to Cobol74 and Cobol80 was supported. Codasyl databases organization required the implementation of a pre-processor to the Cobol programs to extract the data specification from the program. The support of transaction processing required also specific extensions also handled by a pre-processor.

A RPGII compiler was developed from the British designed RPG processor for GCOS62.

The implementation of FORTRAN, C and "standard" PL/1 was easier to integrate that COBOL's implementation.
C compiler was developed in the mid 80's on the Common Compiler Factory, while the GNU C compiler was also ported to GCOS7 to bootstrap the UNIX subsystem.

During the GCOS life, the compilers have been rewritten twice: there was a first implementation able to run in small amount of memory (less than 384KB) and a new implementation around 1980. The new implementation provided the same structure for Fortran, C and PL/1 compilers with an identical intermediary byte code language called OIL (Optimized Intermediate Language)  and a common code generator. However, COBOL that was simultaneously rewritten to support Cobol80 had an asynchronous development cycle and did not made use of OIL.

The output of all compilers was a common binary format called compile-unit format, allowing the mix of procedures written in different languages. The allocation of segments to the compile-units, as well as the building of the address space control blocks is made by the static linker. The static linker builds system objects like thread control blocks and semaphores templates. One of its main functions is to resolve links between the program and the language(s) library(ies). The definitive linkage resolution is made by the loader that allocates actual segment numbers for system shared objects (type 0), those numbers depending on the installation.

TThe limitation of the hardware architecture to a 32-bits word put a heavy limit to the number of segments available to a thread. From the beginning, it became obvious that the default mapping of one procedure one segment was not sustainable, for instance for the scientific library. So GCOS implemented a binder merging several compile-units in a single one, using the architecture feature of multiple entry points in a procedure segment.
The number of large (4MB) segments, allocatable at linkage time, was even more limited. So GCOS created a mechanism of "paging" large data sets in several small (64KB) segments; in particular stack segments are automatically paged.

In addition to the compiled languages, BASIC and APL languages were implemented in GCOS IOF during the late 70s. An interactive preprocessor builds bytes code that is interpreted as a separate interactive step of IOF.
Other processors that run in IOF environment were a line editor and a "run-off" modeled wordprocessor.

  Data bases 

The main data base system, developed from the beginning of the system (along with TDS, in 1977) is IDS-II, conform to CODASYL. The first versions supported only the 'schemas', and the 'subschemas' were added rathet late (1990?). 
An interactive query language IQS was designed to access IDS-II data bases and UFAS files, simultaneously with TDS transactions (TPRs). 
A mini data base system, MLDS was implemented in order to ease migration of GCOS62 customers, using IFAS files. 
In 1982, the choice was made to port the relational data base system
ORACLE, at the time, Oracle Corp was still a small start-up company. Import/export utilities inabled to load/unload from/to UFAS and IDS-II data bases.  Oracle was implemented as a separate server under GCOS7.
A Data Dictionary able to handle file and data base entities was developed in 1981.   

Micro-mainframe links 

The communication with PCs and QUESTAR 400 stations was possible as early as 1986.The access to UFAS files and IDS-II data bases thru IQS has been designed by implementation of 'user agents' regrouped in AFFINITY. 
The File transfer utility TEMPUS-LINK was implemented also, under license from MicroTempus. 

Office automation 

BULL offered starting in 1985  DOAS 7   for the GCOS7 product line. DOAS was a generic name for OA applications intercommunications in the Bull offer.
DOAS 7  regrouped DFA7 (document filing system), X400 mailing system, and the MISTRAL documentary data base system and full-text query, each of them having its own user agent on PC and QUESTAR 400. 
DFA7 (Document Filing Application),  was initially developped by Méthodes et Informatique, then acquired by BULL. DFA7 was  developed in COBOL/TDS.
MISTRAL, was developed by BULL in Fortran and was operating in IOF.


The GCOS7 strategy was originally  to offer    a catalog of applications developed by the Application Group of the company. After 1978, it opens to  leaders in the market place. The reason was to ease the coexistence with IBM, and hopefully a  replacement of IBM machines.

The initial applications  developed outside Bull, were ‘generic applications’ (i.e. complements to the operating system)

  • -The lack of experience within BULL  in the domain of Automated Batch System Planning and Operations ("operator less system’) was overcome by a number of applications developed in COBOL by UNILOG, GENLOG, and some other French software houses they were mainly GCL generators. Accounting and capacity planning applications were also developed.
  • -In the domain of software engineering , to design and generate COBOL applications running in batch mode, and mainly under TDS. SINDIA7 ( by STERIA), developed  in COBOL to generate TPRs, with FORMS interfaces. PACBASE (by CGI), also developed in COBOL to design, generate, and even reengineer COBOL applications to run in batch or TDS/FORMS.
    FOUNDATION (by ANDERSEN CONSULTING), a complete development system in COBOL to design, generate, and reengineer large COBOL applications to run under TDS. The GCOS7 version of FOUNDATION was the reference version for a long period of time. Arthur Andersen    created  a GCOS7 development center  at SOPHIA ANTIPOLIS, in 1989.
  • -In the domain of end user access to data bases : TOTAL, data base system, and MANTIS, enquiry system for TOTAL data bases. ( by CINCOM SYSTEMS) ; both are developed in GPL. Total had been originally introduced for Honeywell H-200.
    FOCUS (by INFORMATION BUILDERS), an enquiry system developed by the french development center of IB, headed by Bernard ELIE, a former GCOS developer.
  • -To build VIDEOTEX pages (for French Minitel), TELESYSTEMES (a subsidiary of France TELECOM) has developed a comprehensive framework in COBOL under TDS to design Videotex applications able to be simultaneously accessed by several hundred of end users. Moreover, the Bordeaux software support group of the Bull French sales network has developped a similar application called MOSCATEL.
  • -In the domain of tools for help in decision making, some applications were developed in APL : LIS ("Langage d’interrogation statistique"), developed by a small French software house. A group of 3 applications was designed by CISI : ATHESA (4GL), CISIGRAPH (graphic package),, and PRIAM (for computations on tables of numbers).

A number of sectorial applications have completed the offer.

  • -In the financial domain, FCS, a financial package developped in COBOL.
  • -In the domain of industry, IMS7, developed by BULL in COBOL as a set of TPRs.
  • -In the domain of insurances, a set of packages developed by GROUPAMA under TDS/COBOL, used primarily in all GROUPAMA subsidiaries, and by other insurance companies.
  • -A number of packages in the domain of medical care have been developed under TDS/COBOL by some CHU, and marketed jointly with  BULL's  French medical sector department.

Finally, one should underline that the port of UNIX on GCOS7 was made in order to gain access to all applications available in the UNIX environment. Bridges with the GCOS7 environment were organized to make it possible to communicate between both worlds.


Other Operating Systems.

In spite of  changes in  names  and even  if the original GCOS64   code in GCOS7 remaining after near 30 years does not exceed some data declaration, there has been one single customer visible operating system maintained by Bull.

NEC, the Japanese company that acquired from Honeywell the licence of GCOS64,  on its side, maintains a cousin version called ACOS-4.
ACOS-4 differs from GCOS-7 essentially by its subsystems modeled on IBM MVS. The transaction environment is quite similar to IBM IMS/DC , the interactive operation is similar to TSO and the networking software DINA modeled on SNA. The reason is that NEC had to compete with Fujitsu, Hitachi and IBM, all offering IBM-like operating systems. ACOS-4 targets also higher levels of performances than GCOS 7 and supports the XSA architecture enhancements.

A few other Operating Systems  had been implemented, but they were Customer invisible OS:

  • A hardware debugging and trouble-shooting environment called Micro-OS for "opels" (individual instructions testing)
  •  a stand-alone monoprogramming monitor for critical peripheral trouble shooting called SCP (support control program).
    SCP is also used in the initialization phase (named then SIP) and has been used in 1974-1975 on the early systems delivered in stand alone G-100 emulation mode.
  • The H-200 stand alone emulator, developed in Boston, used initially another stand alone OS. known internally as the "4A-Backup". Considered for some time (mar 1973-mid 1974) as an alternative to GCOS64, it was eventually shut down. Some of the 4A-Backup design characteristics were  ported to the GCOS6 mod 600 a time-sharing operating system for the high end DPS-6.

© 2001-2003 Jean Bellec