|
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). 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. 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. 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! 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. |
© 2001-2003 Jean Bellec