SECTION II
GCOS computer model
Files
System and computer address space
The first
computing systems, derived from punched cards processing, dissociated completely the
concept of files from the processing instructions. The Von Neumann architecture and the
introduction of time-sharing interactive systems created a new approach that merge the
concept of files and the computational space. Files were user creation as well as programs
and the most efficient view was to consider them similarly. MULTICS added to this new view
the concept of sharing that had been ignored by many of its time-sharing predecessors.
GCOS did NOT
adhere to this MULTICS view of files. Instead it considered files as being independent
from the users. Very often, files were created well before the introduction of a new
system, and they are essentially persistent after the life of that system. Files are
handled by GCOS as they were in their business processing predecessors (Gamma 60, IBM
S/360, GECOS III).
That choice meant that files are not just a succession of bytes (defined by length or
terminated by 00x,) like in MULTICS or some of its successors, but may have an
intrinsic structure and are never put inside the address space of a computation.
Files, in GCOS, are OPENed and CLOSEd and a program has to work in windows of the file
through the appropriate access methods respecting the structure of the file.
Application programs windows in the file are named buffer segments that are protected by
the segmentation mechanism. The syndrome of violating the system protection through buffer
overflow has been stranger to the GCOS architecture.
The time-sharing
systems used generally the concept of a process per user and run all programs requested by
the user inside this process address space. This paradigm was NOT chosen for GCOS. One
reason was the batch applications are submitted in general by one user, the system
operator. Another was that the amount of system resources varies significantly according
to the type of computation: resources needed by a compilation are different from those
required in sorting tape files...There was also a suspicion of a lack of reliability of
hardware and application software that would lead to consider that a job step be
associated to a stable check point of the file system. By moving the file system (i.e. the
volumes that contained the files) to another system, it will be possible to restart a job.
It should be remembered that the duration of a batch-processing job was frequently
measured in hours more than in seconds at that time.
Consequently a job was divided in job steps. For each job step, resources were allocated
and a new process group environment was created. At the end (normal, caused by
errors, or killed by the operator) of the process group, the environment was destroyed and
the resources still allocated were relinquished.
Compatibility
GCOS was running
on a family of computers Level 64, DPS-7 and DPS-7000. The design of this family started
in 1967 as a new product line within General Electric. The decision to build the systems
was achieved at the end of 1970 after the merger of the computer operations of Honeywell
and GE. It was contemplated then to replace all current product lines with the new
products named at that time NPL New Product Line.
However, the development cost to replace the whole existing products exceeded Honeywell
resources and the replacement of GECOS III systems was delayed indefinitely.
Relatively soon in the design of NPL, in 1969, it was decided that the smaller member,
designed in Italy, would not be fully compatible with the main line. Segmentation was
reduced to support only a code segment and a data segment per process. What became
introduced as GCOS 62 had only data types and a non-privileged instructions compatibility
with GCOS 64.
Honeywell decided
two introduce NPL products (under GCOS62 and GCOS64) and to reintroduce GECOS III as GCOS
66 under a weak umbrella named the Honeywell computational theater that emphasized
source language compatibility within members and neglect actual commonalities between
operating systems. While such a concept made some sense to users not concerned by the
inside of their system, it increases the development costs for the manufacturer that had
not only to develop three operating systems, but also to develop features to ease the
migrations between the OS. A technical solution to adopt an interpretive common object
language such as Java became in the 1990s was not conceivable in the 1970s, because the
"fait accompli" of binary programs available on GECOS III and the low
performances of processors of that time. JIT (Just in Time) compilers were out of question
then, the time to compile even a small program was expressed in several minutes!
So the policy that Honeywell has to adopt when it decided not to phase down GCOS III in
1973, could not be considered successful and many successors of Level 64 and Level 66 had
to be built at high cost before main frames started to doom.
As all the
emulations strategies had been a technical success, it may seem surprising that Honeywell
and Bull were not able to adopt it internally. That has been considered, at least by
engineers, from Level 64 to Level 66, in the 6XXX project in 1972, from Level 62 to Level
64 in Gemini project in 1979 and by NEC on its ACOS2/ACOS4 lines in 1985. The changing
multinational organization structure was the more obvious cause of this failure, and the
"Not Invented Here" syndrome in engineering organizations did the rest.