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.
|
|
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]
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. 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. 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. 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 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 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. 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. 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. 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?). 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. 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. Applications 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)
A number of sectorial applications have completed the offer.
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. 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. A few other Operating Systems had been implemented, but they were Customer invisible OS:
|
|
BIBLIOGRAPHIE
|
© 2001-2003 Jean Bellec