|
[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. Outline of the software architecture. A characteristics, somewhat borrowed from Multics and included as part of the hardware architecture, is the use of a hierarchical segmented memory. Another one is the implementation of a micro-kernel, the code part of which being implemented in a separate memory (originally in ROM), that was in that time just named "firmware". [Actually, the "firmware" in a strict definition was written in the microcode of the hardware machine, and the L64/DPS-7/ACOS4 product line implemented around half a dozen different microcodes. Most part of the firmware constituting the micro-kernel was implemented in native instructions but located in a completely separate address space (under-BAR memory and ROM in some models). The data part of the micro-kernel was implemented in RAM and included the system tables, part of the "interior decor" of the system. The "interior decor" is the "principles of operation" used , in part or in totality, by all the software programs programs running in the machine in "native mode". The native mode is complemented in some systems by one or several "emulator modes". The objects handled by this micro-kernel are "threads control blocks" (then named PCB for "process control blocks"), threads dispatching and priorities, semaphores with optional messages for thread synchronization, including "channel programs" handled by specialized I/O hardware, procedure call and return as well as stack management. Four protection rings with read, write, execute
(with gating privileges conferred to some procedures) were also provided by a combination
of hardware and the micro-kernel. Ring 0 has access to privileged
instructions and memory control tables. Ring 3 is the user mode. All the software was running in this structured mode, including the bootstrap and the tests. The software was implemented in the form of "process group" (a set of threads that may share a partly common address space). Process groups could be a single threaded batch job, a multi-threaded application, a subsystem (for instance the Transaction Driven System, the Unix subsystem implemented in the 1980s), a part of the operating system (input reader, output write, communications handler) or the system nucleus itself. The address space of a thread includes common shared procedures and some tables (type 0), dynamically linked segments (type 1); process-group shared segments (type 2) and thread private segments (type 3). Synchronous operating system services were implemented as shared procedures (their ring number depending of the need for protecting shared data. Asynchronous services were running as threads of the nucleus process group, through semaphores and messages queues. Such services frequently had a stub in the user thread space to perform synchronously the request if the resource is available or asynchronously if it is busy. Stubs also were used to pass long messages requiring parameter evaluation or name changing. During the time where memory was scarce and processor very slow by modern vision, an effort was made to run as much as possible the services in the synchronous mode, without compromising the security. Synchronous mode is sometimes called "process/kernel mode" in some more recent operating systems. Many recent operating systems run all related threads of the same process in the same address space. GCOS64 segmented the address space at the thread level to isolate threads related to a transaction against other. Overrun of threads may come of the application programmer design error and it was considered as mandatory to protect a resource as rare as virtual storage for example. As GCOS 64 marketing objective was not focused on intercative processing the relation between users and processes was not built into the nucleus of the operating system but was the responsability of the responsible subsystem (TDS for TP operations, IOF for the time-sharing operations). 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. 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. Performances Improvements 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 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. The reason for such division of work between the name resolution
processes is in part historical but also was made to the constraints of being able to
develop programs and to execute them in separate systems. The 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
grouping 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) -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. -In the domain of end user access to data bases : -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 : . 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. 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, on its side, maintains a cousin version called ACOS-4. 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) and a stand-alone
monoprogramming monitor for critical peripheral trouble shooting called SCP
(support control program). 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.
|
| Index |