MISC | ||
In this section, several aspects of
GCOS covering features encountered within its development will be examined:
Physical Memory Level 64
architecture could address up to 256MB (28-bits byte address). As Level 64 hardware was
limited to 1MB of physical memory by physical constraints (9000 chips on prototypes, 2250
chips on production model), the limit appeared reasonable and the extension to more than
256 MB might be designed without limited impact. The initial limit was 16 times that of
S/360 designed 6 years before. The production Level 64 got RAM cards of 16KB. A memory
size of 256KB meant one card cage of 16 cards and a fully configurated 1MB memory
represented a complete cabinet (with electronics and power supply). Level-64-DPS were
shipped in 1978 with memory chips of 16K bits, decreasing by a factor of 4 the size of the
memory that was integrated in the CPU cabinet. P7G was delivered in 1982 with 64Kbits
memory chips -the 64Kbits chips was the most difficult to pass by semiconductor
manufacturers and the physical memory was extended to 2x4 MB. Number of J The limit of 256
job steps was relatively comfortable until many interactive users worked in the system.
The limit was initially encountered by NEC that had made the choice to allocate a J per
interactive user. They kept some J with up to 255 threads and while limiting the number of
other limited to 16 threads. So, they succeed to have around 1000 J. Their design was
adopted by Bull in 1986 but had a very little impact on GCOS. Virtual Address
Space The address space
both in terms of number of segments and size of individual segments appeared a significant
restriction soon in the 1970s. Two "escape" mechanisms were implemented the
large 4MB segments and the type 1 segments. In addition, the limited address space
inherent to a 42 bits machine was one of the reason of the destruction of the address
space at each step of a batch or an interactive job. Actually, systems like Multics were
forced to rely on a "flushing" of the segment tables and a reconstruction of the
dynamically linked space when limits were encountered. The decision of considering
segments as buffers and not as part of the file system helped a little bit. It was also
possible to segregate operating system functions as separate process spaces to increase
the total address space. Changes in that
area were very difficult to make as other products lines had experimented. New software
releases had to work on various "old" processors for customer convenience and to
decrease maintenance costs. New hardware systems were introduced only at both ends of the
product line. For technical and
"political" reasons, an extended architecture XSA was designed in the late 1980s
jointly by Bull with NEC. When implemented, it would have allowed the removal of the
constraints of the limited address space. However, only some parts, like extended physical
memory space, were eventually implemented by Bull and NEC last processors were not
marketed by Bull, nor the extensions made to GCOS. Segment size Most of the
address space was available on segments limited to 64KB, not a strong limitation for
procedure segments -forcing system and application programmers to modular components-, but
for system tables that were limited to use less than 64KB. As tables might include several
hundred bytes per item, that segment size was a limit frequently encountered. The way to
go around those limits was to allocate a chain of segments or to undertake a more
significant redesign regrouping several tables in a large segment as in non-segmented
systems, taking care of non-introducing security flaws by that way. Methodology,
Integration and Delivery The size of the
project required an intensive work on integration and delivery methods. The architecture,
per se, was not enough to maintain a good product. The development was divided into
working groups producing system integration units, a collection of "debugged"
(alpha-tested) source code, and documentation of a functional area. Source code was
originally coded, compiled and run in simulation mode under Multics on a GE-645. When
Level 64 hardware became available, Multics role became more that of a repository of the
source code. Flow charts, when used, had to stay off-line. System calls,
visible to applications or internal to the system were defined through HPL and/or MLP (and
later C) macros. Those macros were expanded along with local programmer macros by a
macro-generator pass before compilation. That procedure worked well as soon as all
modifications were made in source form. However, the releases of the system were made on
an yearly basis and corrections were required more often. If some corrections were done in
source form and led to large amount of patches, frequently the correction was delivered
only as binary (i.e. hex) patches and done also separately in the programmer source code
for the next release. The documentation
of the customer operators and programmers was produced by technical writers from draft
documents written in English by Bull programmers. That documentation was not always
available for beta testing by Quality Assurance people. Beta testing was never officially
at customer sites, although several products were introduced as "RPQ" for
specific customers supported directly by Bull personnel. GCOS descriptions included
flowcharts, table descriptions, and internal interfaces. Those documents were written by
developers, edited by support people and distributed as microfiches to support in Field
Engineering. NEC ACOS
systems NEC acquired a
full development license of GCOS as part of an agreement with Honeywell made in the 1960s
and renewed in 1972. A few NEC engineers participate to GCOS 64 project as developers and
the first ACOS4 release was almost identical to GCOS64. It differed only by a support of
Japanese language, while their reference documentation stayed in English. NEC continued to
have access to GCOS products in the 1970s, with the exception of HDSA products. NEC used ACOS 4 on
their high performance systems, including until 1985 where it was replaced by UNIX,
on their supercomputer SX systems. They supported their own data communications systems
and their own line of peripheral. They implemented paging, based on a 1974 common design
with CHB, on their systems starting in 1980. NEC chose to
design its interactive operation in a way inspired from IBM MVS. Networking adopted a
mainframe centric architecture similar to SNA. Interactive processing was mapped on TSO
architecture. Transaction processing was inspired from IMS/VS where a queuing server
distributed transactions to specific servers organized by transaction type. In 1985-1986, Bull
renewed the cooperation with NEC, borrowing the design of the paging mechanism from them.
However, both companies pursued their way on their software, exchanging presentations and
ideas on innovative areas. Conclusion GCOS 64 and GCOS 7
were the successive names to the same continuous design. If other software systems showed
a similar history, it is the only European software that had a comparable life: from old
card batch oriented applications toward powerful transaction servers. It suffered from
the complexity introduced by the layers of functions introduced with time, from limits due
to the high cost of hardware at the origin, from some dogmatisms in some areas that were
circumvented more than corrected. GCOS was overall designed and managed for
manufacturer-designed software. It respected industry de facto interfaces (i.e. IBM) more
than other Honeywell and Bull systems but it ignored for a too long time the world of open
systems. It will survive
some time to the abandon of its genuine hardware designs by being hosted in a SMP Intel
architecture (initially IA-32, eventually IA-64), coexisting on the same enclosure with
operating systems of other servers, serving the applications now becoming obsolete or
not performing enough under GCOS in an open networking environment. |
© 2001-2003 Jean Bellec