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.