[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 |