of Bull 140 project (end of 1966)
The origin of the Bull "New
machine" may be traced down to the cancellation of the
The G140 project was the first
system the design of which was started at Bull General
Electric after the GE merger of 1964. Other systems
such as Gamma M40, Gamma 10 and GE-55 were sold by B-GE -and
the latter by General Electric in the US-but designed at the
time the company was still Compagnie des Machines Bull.
The 140, later announced as GE140, was a medium range system
16-bits wide designed for tape and disc environments ; the
disc version was never physically delivered to customers.
The design of its software was later "exported" to
the CII for the design of CII IRIS 50, the software
chief architect of the 140 software being François SALLE.
Initially, the 140 had been designed as a member of a common
product line containing GEISI –General Electric
Information Systems Italia– GE115, designed also before
the GE-Olivetti merger, that was sold very successfully by
Bull General Electric
However, the G140 program was also
competing in fact with another GE system, a 24-bit
second-generation computer named the GE400 developed in
Phoenix AZ. As that of the GE-400, the G140 technology was
conventional built on discrete transistor components,
although Bull hardware labs had designed modular elements
called "mini-modules" that could have been
eventually integrated in ICs.
The G140 program was canceled by the
end of 1966 a little bit after its marketing
announcement in Bull-GE territories. Among reasons of the
cancellation were the internal competition with GE400, the
lack of line image of the GE-100 and the relatively high
development cost combined with Bull General Electric's
lack of money. It should be remembered that in this period,
computers were leased from the manufacturers and
manufacturing new computers was, for the company, a capital
drain that required several years to recover.
The 140 cancellation caused a big turmoil in Bull's French
Marketing and in Engineering. Bull-GE was very
quickly deserted by many of its engineers who joined the
Government subsidized CII that was just been formed.
The end of the 140 project was that the Czechoslovakian
company Tesla acquired the license of G140 and the
manufacturing rights for that system. A few hundreds were
produced in the late 1960s and the early 1970s.
Launch of project
As a conservative measure to
keep some engineers on board, BULL-General Electric, with GE
agreement, assigned to Pierre DAVOUS, assisted by Georges
LEPICARD, an exploratory mission to specify a line of medium
sized machines that could be sold competitively with IBM 360
–the IBM product line then emerging then as a definitive
success–. By medium-sized machines was meant systems at
IBM 360/50 level and below, excluding what used to be the
IBM 70x/70xx class of customers. It also excluded systems
derived from accounting machines that were to be the then
succesfull GE-55 machine. More explicitely, the line should
be substituted to the GE-100.
As its IBM competition, it was
planned that the line of products would have to be
micro-programmed, a technique that the Bull team was the
only one having experimented within GE with the projects
M40 and GE140 (and the GE-55). Other GE -even GEISI- systems
were hard wired.
This project received the name of "Project
CHARLIE". A few Americans
from Phoenix engineering, noticeably Izzy EPSTEIN, joined a
research team of around 20 French people.
Some of the basic design options of
the DPS7 have been taken during this study. Particularly, it
was decided to adopt an architecture now known as CISC using
32 bits registers à la S/360 and to introduce some MULTICS
It was also considered that real-time transactional
applications should merit a firmware implementation of the process
(presently named threads) dispatching mechanism. A
first draft of the instruction code set was established. It
was planned to stay with a classical model of a Van Neumann
architecture, even if software was inclined to separate code
from data. After a minimal evaluation of an interpretative
language -such as BASIC-, it was decided to keep a more
conservative approach of having compilers preparing binary
The different models of the Charlie were contemplated to
differ essentially by the width of their data path (16 and
During this period at mid-1967-, GE
hired an ex-IBMer, John HAANSTRA, as vice-president
He took a direct interest in the design options of the
CHARLIE project. John HAANSTRA recommended that the
peripheral controllers (PCP Peripheral Control Processors)
be micro-programmed, avoiding special logic as much as
possible, and the Bull URC -- that was later followed
by its cousins like the Phoenix MPC and the NEC URP, was
initiated by Henri VERDIER team on the base of J.HAANSTRA
In parallel, technology studies were initiated: while the
choice of integrated circuits was obvious (RCA had already
shipped its Spectra70 line), several solutions were possible
for the transistors types. GE had started in Schenectady the
study of CML – a variant of ECL, slightly less
power-hungry– and CML was a potential candidate for the
new line of systems in parallel with TTL.
Another assumption was that main memory would be still
implemented with magnetic cores, what impacted significantly
the cost of the system and put considerable pressure on
General Electric L178 Product Line
A GE Management review took place at
the end of 1967 and it was decided that the Bull-GE Charlie
study should be the base of a modern GE product line
essentially targeted to replace GE-100 and GE-400 product
This product line should have been
designed jointly by GEISI, Bull and the GE400 team of
Phoenix. The GE600 team of Phoenix was then busy fixing
design and implementation problems in both the GECOS3 and
the MULTICS systems and was let apart of the new design. On
the contrary, ASTO research center in Phoenix, directed by
John WEIL and Mauro PACELLI, was to be deeply involved in
It was decided to review the options
of the Bull study (project Charlie) and to launch a project
called L178 product line composed of three models:
- E120 as a 16-bit low-end
machine assigned to GEISI,
- R370 to be developed by
Bull General Electric
- W108 a more powerful
system to be developed by GE Phoenix.
A strict security system, à la IBM,
was instituted for the new design. Code names were formed
from the initials of the project manager and documents were
classified as GE class4 for all business planning and
financially sensitive matters and class3 for technical
matters. Class4 documents received a number for each page
and they were distributed according a centralized and
nominative list of distribution. Class3 documents were
distributed according "need to know" lists of
distribution. It seems that no leak to the press or to the
outside occurred during that phase of the design .
The project started
effectively in January 1968 under the effective
direction of Eugen R. WHITE as project manager
reporting directly to John HAANSTRA. A coordination team was
assembled in Phoenix ;
the chief architect was Georges LEPICARD from Bull-GE,
the software project leader was Leroy ELLISON from GE
Some Bull hardware architects from BULL --G.BARONNAT and
G.de PONCINS, joined the Phoenix team and stayed there with
Georges Lepicard for around one year.
Specific program managers were
assigned in the different organizations to coordinate local
work and to report to the overall program manager.
Jean-Pierre HARDY was named program manager for the R370 to
be developed by Paris.
The architecture was coordinated by
George LEPICARD and discussed between the CPU architects,
the compiler designers of ASTO and the Paris software people
for the kernel (then called nucleus) requirements.
The first draft of the "Interior decor" –this
term was coined at this time by ASTO software people– was
published by September 1968.
E120 Compatibility. Origin of
Level 62 divergence
The E120 architecture was in
october 1968 "accepted" as being a "subset"
of the main line "interior decor". The arguments
were that the cost of the segmented architecture implied by
the associative memory penalized abusively the cost of E120
processor and that a low-end machine should keep integrated
peripherals and should not support the implication of I/O
channels management. While real, the decision to diverge
simplified the management of the project by not addressing
the long rivality between the French and the Italians.
Consequently, a large autonomy was given to the designers of
what became eventually the Level 62 about the design
of their architecture and their software. The divergence
between DPS4 and DPS7 took place in 1968! However, at that
time, it was still implied that the upper range of the line
should be able to operate in the lower level
"mode"; this specification was later dropped.
During the Charlie project, it was
envisioned that the E120 decor had to be the same as the one
of the PCP, so that a single engine could be used on the
subsystems and on the lower end of the line. This last
approach was abandoned by November 1968, at Paris request to
use a minicomputer 16-bit decor instead of a variable length
"main frame" decor for the PCP.
The E120 project subsisted through the GE-Honeywell merger
and gave birth to the Series 60 Level 62 product line
to be followed the DPS-4 and 4000 until the mid-1980s.
A proprietary high level
Implementation language for software development was planned
: Q-language, an ALGOL60 derived language,
was designed, but actually never implemented.
The assignments of Software tasks to
the development teams of Bull and Medium System Department
in Phoenix were made: Bull abandoned for some years any work
on COBOL, while some competence in basic operating system
was attributed to what was then a very inexperienced Bull
team, under the responsibility of MIKE BAILEY, reviewed the
results of the preliminary software studies. That report was
essentially confirming the initial design decisions about
the use of segmentation, condemning demand paging in
the sake of performances, recommending however paging as a
tool for memory chunks allocation. It was insisting on the
use of a powerful Macro-generator, both as a software
methodology tool and as a job control language extension. It
also let Management unwary about the "subsettability"
of the interior decor, assuming that segmentation mechanism
could be specific to a hardware model, without impacting the
It might have been that ACT was hunting from contracts in
several GE divisions!
That period was marked by a
cross-culture exchange in the software area between the
GE600 world, the S/360 influence on Bull designers and the
Burroughs culture that predominated in ASTO. The role of
ASTO's Jack MERNER, one of the key architects of the
Burroughs B5000, and that of Mauro PACELLI, head of sofware
ASTO unit, should be specifically mentioned.
The Bull initial interior
decor was then complemented by the implementation of
a stack mechanism handled by firmware for parameters
passing, while the arithmetics remain in S/360-like
The general conventions of a static
linkage mechanism were established. The introduction of the "process"
concept in the interior decor was confirmed, although many
designers from GECOS3 and MULTICS were very reluctant to
freeze the software design of those architecture elements.
[Note that L178 Processes are called threads
in recent Operating systems terminology.]
The concept of Process group
and its identification as job steps' occurrences were
introduced during that period. A process group could be a
multi-threaded iser job step, a subsystem or a
multi-threaded server. Most of user applications were to
remain single thread process groups.
A "Smart indexing", i.e.,
indexing modulo a length dependent upon the operand type was
Retrospectively, it appears that too
much importance was given to the ease of implementation of
some languages' features by compilers at the expense of CPU
performances for high-end machines. It was assumed that all
the machines would be micro-programmed (in PROM), a
difference with the S/360 decor where the assumption was
that the majority of instructions. should be hard wired-on
in the upper end processor.
A use of ASCII code was
planned at that time because IBM was then to have an ASCII
mode on S/360 and because the overall culture of GE Computer
Division was extremely reluctant to target any kind of IBM
compatibility, such as the EBCDIC encoding , that was
Two Technologies were considered : a
SUHL Sylvania technology as used in the GE655 and a CML (Current
Mode Logic) technology developed in GE laboratories.
Eventually, the CML was chosen as the base of the study,
probably due to an intense lobbying of research people in
front of John Haanstra, a manager who remained
Although the level of integration of
CML was at that time extremely embryonic, that technology
was chosen for its performances and its low power
consumption (relatively to off the shelf ECL's) .
The main memory was assumed
initially to be magnetic core in spite of its labor
intensive cost figures ; at that time, GE was planning to
set up a core weaving factory ...in the Navajo reservation!
You should note that the intended manufacturing cost
("shop cost") of a 32-bits CPU was planned
to be 8,900 1970-dollars, while memory's cost was expected
to be 8,000 dollars per 32K Bytes!
The R370 CPU was to be developed in
Paris - under the direction of Jacques BIENVENU ; it had to
be based on hardware blocks, planned to be common to all the
components of L-178, called SOMA (System Oriented Macro
Assembly). Those SOMA were envisioned to be eventually
LSIfied in a future version
The peripheral controllers of the
main line were to be developed on a common design of the
Bull URC, while E120 peripherals had to be "integrated"
and controlled by the CPU firmware..
The overall architecture of the
PSI Channel --Peripheral Subsystem Interface,
was drafted at that time.
Because the 8-bit byte orientation
of the L-178, the PSI had to be a parallel 8-bit channel.
For data integrity reasons, due to the relatively low
reliability of the subsystems of that time, it was excluded
that PCPs had a direct access (DMA) to the main memory and
decided that those accesses had to be controlled by the CPU
A separate IOC (input-output
controller), regrouping the channels' access to the system
memory, was not envisioned at that time for cost reasons. It
was also considered that the PSI should be the
"long" cables in the system because the interface
between the PCP and the devices might have to be specific
and ought to control a "real-time" interface. This
general design was later adopted for both the new product
line and the GE-600+ line. In the latter, PSI channels --
although never actually identical to the NPL ones, supersede
progressively the old (1965) Common Peripheral Interface (CPI)
6-bits wide channels.
It may be interesting to note that
the main Discs that were contemplated at that time were
removable discs with a 17MBytes(!) capacity and a transfer
rate of 468KB/s. Future (1975) discs with up to 300MBytes
The L-178 systems remained punched
card oriented. GE was assuming a development of
optical- reading of documents that was never materialized.
Impact printers had, at that time, already reached their
maturity (at 1300lpm).
The expected reliability was poor in
face of present standards, no more than a MTBF of 100 hours.
That was due to the low level of integration of the
technology and consequently to the amount of connectors and
cards existing in the system. It was expected to spend a
large amount of hardware to check the system data integrity
and to insert control probes.
End of L-178
At the end of 1968, the results were
not satisfactory in the technology and hardware design areas:
the building blocks (SOMA) were too numerous and the CML was
not ready to be used by the 1970 time frame.
John HAANSTRA was asked to take
direct responsibility of Phoenix engineering to reorganize
the GE655 project --alias GE6000--, and Gene WHITE left the
Bull-GE reconsidered the R530
project in a more conventional TTL technology as a System730/30
and the Italian acted similarly.
Phoenix MSD -Medium Systems
Department- was disbanded and merged with LISD (the GE600
|GE then hired a new
manager with a more business background, Richard
("Dick") BLOCH from Honeywell. Dick was instructed
to take a more business orientation for the new Product line
and to prepare a grandiose plan on which GE could take a
decision to "lose or win" the computer business.
This plan was to be designed by the Shangri-La project.
It should be reminded that 1969 saw
the first abandon of a computer manufacturer company: RCA
retreated and sold its business to UNIVAC.
To set such a plan, R.BLOCH
assembled at Hollywood-by-the-Sea, near Fort
Lauderdale Florida, during the summer of 1969, a large set
of specialists from all the branches of the Company
including from the Corporate Lab of Schenectady- with Robin
KERR from the software department, and from the MULTICS lab
with André BENSOUSSAN on loan from Bull.
Bull sent Planning people such as
Michel JALABERT , Raymond CHAUVEAU , Bruno LECLERC etc....Engineers
were selected from departments not presently involved in NPL
such as Claude BOUVIER the chief architect of GE51 and
obviously some of the architects working on "NPL"
such as Georges LEPICARD in hardware, Jean BELLEC and Claude
CARRE in software. GEISI had notoriously Marisa BELLISARIO
and also Paolo CESA BIANCHI, Mario ROSSI and other engineers.
The "main team" of around
50 people stayed assembled from July 1 to the end of October,
while numerous people were called to feed in information,
such as Marc BOURIN for technology and the Bull hardware and
software designers involved in the previous steps of the
Managers from GE and subsidiaries --J.P. BRULE who joined
Bull GE around this time, Tom VANDERSLICE who was then
Peripheral division manager - also attended the meeting for
a few days. John HAANSTRA died in his private airplane crash
when coming back to Phoenix from Florida.
The fall-outs of this meetings were
many: but, above all, there was a cross-culture
confrontation that was extended to market analysis and
The objectives were to increase
significantly the GE market share and to provide a
homogeneous offering on almost all market segments.
Marketing studies mapped very closely computers' size and
customer's size and the major bases for market analysis were
"migration tables" based on existing systems and
customer loyalty estimation. Vertical segmentation was
essentially ignored and software inertia was underestimated.
Professional market analysts as J. Diebold or IDC had not
yet appeared at that time and the computer manufacturers had
to rely on in-house analysis.
The disappearance of punched cards
for data entry was now expected, but key-to-tape off-line
systems were expected to compete successfully against
on-line data entry.
Disc based operating system was
expected for all members of the line.
Some of the main technical detailed
decisions that have been taken during that period, were to
use a Semaphore mechanism for process synchronization and to
give priority to the segmentation of the address space
instead of paging a single address space if the hardware was
not able to get both economically.
As software products, the experience
in the, then emerging, Codasyl Data Base organization based
on GE IDS was brought by Charlie BACHMAN into the technical
culture; the importance of database journalization and
roll-back was brought in by Russ McGHEE from the WEYCOS
project --an early transactional system based on GCOS-II on
GE-600 for the Weyerhauser Company.
The formal output of the Shangri-La
meeting was a Master Project Plan that called for a
new Advanced Product Line (APL) with four models:
- A-model was to be a very
small business computer,
- B-model was essentially
what the Italian had defined
- Bull and Phoenix had to plan for
two fully compatible models the D-model (Bull)
and the E- model.
There was no technical C-model
because GEISI had "demonstrated" that the related
market could be handled by the same technical object as
An important output of the Shangri-La
meeting was the importance given to the problems of park
conversion, both internal and external.
The Emulators that were taken
in consideration by the meeting had been:
- the GE100 for which the
"C" and "D" systems were targeted,
- the GE58 for which the
"B" was shooting, although some Bull designers
did not desperate to have the GE58 being born again as
the "A" system
- the IBM360/20 that was
correctly seen as an orphan in the S/360 lineage. Object
code compatibility with IBM 360 was not technically
taken in consideration.
On the contrary, it was envisioned
that Plug Compatible Manufacturers (PCM) could target APL
for peripherals or memory units and measures were considered
to counteract their entrance on the APL products both in
hardware, in software and in maintenance. Channel
compatibility and device interface compatibility were
excluded that reason. Later, Honeywell experience made the
engineers changing -- somewhat- their mind at this subject.
Weaknesses of the Plan
No Manufacturing plan was actually
established. An unwritten assumption was that each country
would manufacture the systems they design, while some
double- sourcing was envisioned.
The Shangri-La meeting was not very
fruitful in the domains of technology: GE had
expressed that they would buy it instead of making it and
participants had extremely erroneous forecasts when they did
not predict the advent of semi-conductor memories. Shop
costs computed at that time showed to be accurate a few
years later, but memory sizes were widely underestimated and
led to some errors in software future design. The meeting
also underestimated the importance of transaction
processing and completely failed to predict the advent
of personal computers.
The evolution toward distribution in
departmental systems, and multi-vendors'
systems was not identified at that time as part of the
market requirements. The identified sources of business were
the replacement of existing systems and new
applications. The important revolution what was emerging
i.e., the evolution from batch processing to on-line
processing was not given enough attention especially in
The main cause of inefficiency
during the meeting was due to the parochialism of the
participants which was generally encouraged by their
hierarchical management because it was assumed that
manufacturing was the major source of profitability and
that it had to be closely located near the engineering.
It was understood that R.BLOCH
intended to build a new engineering organization in a
new location, i.e., BRIDGEPORT Conn. and that selected
participants will have to move there and some will have to
expatriate. As almost all participants did not intend to
start from scratch their professional --and sometimes
personal life, so there was a considerable reluctance to
follow a person who never imposed himself as a charismatic
Just after Shangri-La, Bull
reorganized its engineering to be able to take a strong
position in the incoming bargaining.
- Marc BOURIN took
over both Engineering and Planning for the future Medium
Systems machine, replacing Pierre DAVOUS
- Thierry CHAIN took responsibility
of Software, replacing Jean Paul BOSS.
- Hardware Development was then
split between Christian JOLY for technology and
- and Georges LEPICARD for system
- André RIVIERE was named in
charge of Marketing and Planning.
- Product Planning itself was under
the responsibility of Jean-Philippe BECKER assisted by
Jacqueline VIDAL, and Lucien NEGRE.
During the period of November 1969
to April 1970, each organization was continuing work on its
own part of the project. A relatively weak coordination was
held in Bridgeport under the authority of Robin KERR for
interior decor and software and Al CONOVER for hardware and
A commonalty with IBM S/360 I/O at
channel- program software level was studied at that time to
evaluate an S/360 emulation. The general specification of
the PSI channel was specified and particularly its radial
configuration as opposed to the multi-drop IBM channel.
Bull performed an analysis of a
paging architecture in measuring the sensibility of the
operation of IBM OS/MVT running under CP67 on the Grenoble
University 360/67. It should be remembered that main
memories were still extremely small and that it was
requested to operate a full functionality operating system
on 64KB, and there was even a proposal to run such an OS --
with paging, into a 4KB memory for the low-end "A"
Honeywell takes over
General Electric withdraws
from the Computer Market.
GE Corporate Planners and Finance
people examined the results of the Shangri-La meeting that
were presented by R.BLOCH as an "implement or die"
gambit. The finances of GE were drained out by other
technology oriented projects that were nuclear energy plants
and airplane engines. So GE Management decided to go out of
the business and to look for a buyer. They finally decided
to sell this business to Honeywell.
Honeywell was faced to a
similar need for growth and had R&D cost problems.
Honeywell Boston designers, during the same summer, had
meetings similar to Shangri-La in Cape Cod, but in a less
grandiose show. However, Honeywell killed their internal ACS
(Advanced Computer System) project, essentially for
technical reasons. ACS was an object-oriented machine, the
performances of that being not able to compete against more
Honeywell decided eventually to buy
the General Electric computer business that brought to the
venture a strong distribution network in Europe
especially in France and in Italy as well as uncommitted
engineering development forces in several countries.
Honeywell was then proud to post billboards calling out
"The Other Computer Company".
Honeywell assessment of APL
Honeywell was impressed by the
output of Shangri- La on the points of business planning and
technical matters. It decided to look at the GE APL project
with an extreme interest.
In BULL, in July 1970 a small team
of 4 people -- André BENSOUSSAN, Axel KVILEKVAL, Claude
CARRE and Jean BELLEC, was assembled during 6 weeks to draft
an "Overview of APL Operating System" that
describes the main options of what later became GCOS64. A
decision was made at this time to use segmentation as a
Virtual memory management tool, while its role as a
container of "objects" was precised. It was
decided to separate the universe of the files --the
"file system", accessed through data management,
from the universe of computation: MULTICS was then in the
process to add Data Management to its initial "single
view" of the universe. The decision to implement the
majority of the functions as Procedure calls services (à la
MULTICS) versus the operation of those functions under
servers (monitors), with the natural exceptions of
functionally asynchronous operations like scheduler, input
reader, output writer... was taken at this time.
Starting from summer 1970, Honeywell
intended to regroup the engineering forces of its units in
BOSTON and the acquired General Electric engineering to
build a new product line able to succeed to the then aging
H2000 product line as well as to replace the GE100 and GE400
The role of GE6000 was not yet fully
assessed, because the Sales network of GE was significantly
weaker than that of Honeywell in the US; the only
significant inroad of GE-600 was GE miscellaneous
engineering departments and BULL-GE had suspended the
marketing of that system in 1967 waiting for a fix of
engineering troubles that plagued it in the 1966-1970 period.
In fact, what happens after the merger was that an
aggressive sales network with only the GE6000 to sell was
able to deeply root this system in the market in less time
that Engineering was able to bring up a new line of
The NPL Organization
Honeywell decided not to break out
its own and ex-GE organizations, at the exception of its own
minicomputer organization -- coming from the CCC acquisition
that produced a line of 16-bit minicomputers, the best known
is the H-316- in FRAMINGHAM, MA which was disbanded end of
1970. People had to move to BILLERICA Mass. to be
incorporated in NPL development teams.
However, for NPL, some Phoenix
engineers and noticeably Charlie BACHMAN, Pete DRESSEN, Bill
FRINK and Ross PARK moved to Boston to work on NPL, in
relation with the French.
ANDERSON took the following decisions under the authority of
Clancy SPANGLE, at that time Honeywell CEO:
- HONEYWELL Information Systems
Italia was given the charge of developing the "Level
1" of NPL,
- HONEYWELL-BULL of France was
given in conjunction with HONEYWELL Boston the
responsibility of developing a "Level 2",
- Some future work was expected to
be given to the Phoenix operation to develop a "Level
3", if and when the H6000 line had taken off
- Honeywell units in UK were to
participate to some work as a subcontractor essentially
The NPL had also important
consequences in Japan
Honeywell started to have an
investigation mission to dig into the newly acquired
engineering forces. Among the reviewers were RF.Anderson
assigned as NPL Program overseer, W.PODUSKA and mainly Ugo
GAGLIARDI from Harvard Computer Lab who was assigned as
the Technical Director of NPL Project. Ugo was given
a small team of consultants as the NPL Technical Office in
Billerica. Giuliano RAVIOLA moved from Pregnana as a general
secretary of the project.
As it might be observed, the Italian
component was subject to temptations of independence because
its assignment to the lower end, and the origin of the key
people of the NPL Technical Office was then seen as a way to
control this temptation.
Jacques BOUVARD was assigned to this committee from the then
disbanded minicomputer operation. His knowledge of French
language may also have contributed to his selection.
Irma WYMAN represented the relationship with the old
Honeywell establishment and particularly its Marketing Arm.
Doris BENCZYK was especially in charge of manufacturing.
In addition, some bright computer scientists, as Jeff BUZEN,
known in the area of performance simulation, and Robert
GOLDBERG, in the area of Operating systems, joined the
Jacques BOUVARD and Charlie BACHMAN
made a lot of work to provide a formal description of
operating systems functions using Charlie's data structure
diagrams methodology. Difficulties for using it came from
the fact that the methodology was not fully assessed for
procedural objects and from the differences in "philosophy"
between Jacques' view of an event-driven operating system
and what was being designed in development houses.
In parallel, an integration of
Product Planning and Business Planning operations took place
and common accounting and costing procedures were
established. However, there was really no attempt to
separate Manufacturing operations from their geographical
At that time, the following plants
were in operation:
- ANGERS manufacturing GE58 and
converting from GE400 to H2000 --a disputable move,
Angers was significantly underloaded in 1971 and was
producing the GE58 small business system.
- BELFORT was manufacturing
essentially I51printers for G100 and G58 as well as card
equipments for all the company. While the 300-cpm
cardpunch of Cie des Machines BULL design was still in
production, the Honeywell BOSTON know-how and the
manufacturing responsibility for Honeywell card readers
was being transferred to BELFORT.
- LAWRENCE (MA) plant was Honeywell
prime source for peripherals (discs)
- HEPPENHEIM (Western Germany)
plant from Honeywell was manufacturing discs, as a
- PREGNANA was manufacturing the
G100 in conjunction with CALUSO.
- The British plant of
HEMEL-HEMPSTEAD was devoted to H316 minicomputers.
- PHOENIX was terminating the
GE400product line and was shipping a few GE600/6000.
- OKLAHOMA was building discs for
GE and was being consolidated with Honeywell
productions. This plant and the Heppenheim one were
later (1975) transferred to Control Data Magnetic
Peripherals Division (MPI) along with the retreating of
Honeywell from that peripheral business.
- Several plants were located in
the BOSTON area:
- BILLERICA was becoming
essentially the engineering plant.
- BRIGHTON was the primary
plant for H-200 manufacturing.
- The minicomputers' plant in
Framingham was closing down.
Mode of Operation
The organization of the Technical
Office was such that the effective design responsibility
belonged to the Development organizations and that the
Technical Office had a role of reviewer and of Project
management. Technical meetings were held for 3 to 4 days
each 2 months in different locations. The technical meetings
were reviewing almost all-current projects and set up a list
of Action Items the accomplishment of that was reviewed at
the next Technical Meeting. The meetings were held in
different locations to allow more "local"
presenters from the host organization. Meetings took place
in Billerica, Paris, Pregnana, Phoenix and even Tokyo.
After a few months, Ugo GAGLIARDI
was also promoted as a manager for the Boston operation
while retaining his responsibility as a NPL Technical
director. he remained perfectly "objective" and
sometimes was obliged to forget the interest of his "parish"
in the conflicts between Paris and Boston interests.
The "Level 2"
responsibility was split between Paris Medium System
Department, under the authority of Marc BOURIN and Boston
Medium System Department where operations were located in
Billerica for Management and hardware design and in Waltham
for software development.
Software was assigned on the
following way: Two nuclei were envisioned:
- level 2B for 'large systems'
optimized around 512KB main memory size,
- level 2A for 'small systems'
The same extended machine
specifications were planned for both nuclei and the same
applications and software tools were planned for both 2A and
Paris was to be responsible for the
small nucleus and for linker and loader components. Boston
was responsible for the large nucleus, for the software
factory and for COBOL compiler as well as for "advanced"
access methods like UFAS Unified File Access System (
essentially a clone of IBM VSAM KSDS organization) and IDS (Integrated
Level 2 Software
After some time, the large nucleus
design was discontinued and all the OS responsibility was
assigned to Paris.
Along the US key contributors of
this period where GCOS64 really was born, we should
mention the role of Charlie BACHMAN. He was working in the
Data Management architecture with Pete DRESSEN on IDS and
Dennis WARD on UFAS design. Paul DERBY was the responsible
for Utilities and End User facilities --the name used at
that time for what became L4G later--
In Paris, the nucleus design started
under the responsibility of Claude CARRE and included the
finalization of the Virtual Memory Management, of Physical
I/O and of Exception Handling.
Alain POUBLAN was, in liaison with
the US, succeeding to design a file organization providing a
large level of independence between the program view, the
access methods and the stored file format. It was decided to
provide several file organizations especially for conversion
purpose (sequential and indexed-sequential à la IBM, H-200
formats), and a unique system access method, named "queued
sequential" was adopted. This method was allowing
dynamic storage allocation and was expected to be used also
for message queues-- that were later implemented through
Job Control Language was to be
extended to several properties of a language. It was later
"simplified" to mimic GCOS3 functionalities and
later extended again in 1979 GCL. It was to be preprocessed
before its execution by a general purpose Macro-generator
that was able to recursively operate on characters' strings.
This implementation made by Claude PENDZEL and Richard
RAPAPORT had proven flexible but CPU time consuming and was
replaced by a more conventional processor by 1976.
The coordination for software was
made by a Software Technical Coordination Committee, meeting
alternatively in Paris and Boston every month under the
control of a Software Management Review Committee (SMRC)
meeting each two months also alternatively on both sides of
the Atlantic. Thierry CHAIN, Jean BELLEC and Jacques
BERNADAT --Bull software program manager, represented Bull
at SMRC while Dick HILL -- hired from Informatics --, and
Dick ANGEL , represented Honeywell. Problems during this
period were the frequency of the meetings (10 transatlantic
flights per year for the responsible people) and the
imprecision of the relative roles of the local management
and of the NPL technical office.
In Hardware, the separation of the
work was the following: Paris was to develop the P7 CPU
while Boston developed the P8. Both systems were to be built
of TTL74N technology and use semiconductor memory.
While pre-production models of
memory were 1Kbit based, production models were initially
1Kbit and then 4Kbits for France manufactured systems, while
Boston planned and actually ordered specially produced
2Kbits chips, by lack of confidence in the technology
progresses. It should reminded that in 1971, the computer
industry was still the main customer of the pioneering
semiconductor companies, such as Texas Instruments,
Fairchild or Sylvania. It had
to wait until 1973 to see the watch and the calculator
business taking over this primary role.
Honeywell management was extremely
surprised by the NEC policy of entering the semiconductor
business in the frame of a "VLSI cooperative
project" set up by the MITI. Honeywell considered that
NEC policy too technically oriented --what is true --, and
that the decision to build VLSI was contrary to the trend of
the business --what remains to be proven--.
The Printed-circuit Boards
technology was named SP-10 with relatively small board size
and was still manufactured in 1987 for tape controllers.
In the Manufacturing and Order
processing area, a new set of nomenclature for NPL
products was established (marketing identifiers --MI-, IPI
and parts numbers...). This was applied to all NPL members
including the new versions of GE6000 (Level 66) and of GE58
(Level 61). This system was still in use in 1990.
Finally the Interior Decor
was finalized. Honeywell Bull was assigned the
"control" part of it, while Honeywell in Boston
was finalizing the "user" part of the decor. The
first part was more subject to the influence of OS designers
while the second one was more sensible to compiler
designers' requests. Among the designers of the
"control" part, it is desirable to name Marc
APPELL, Philippe de RIVET, Pierre SEVRAY and Jean Claude
Among the issues that were debated
during this period, one was the fairness of the choice of EBCDIC
8bit byte in place of 36 bits words of the GE6000. It was
argued that 9bit bytes were able to support both EBCDIC and
ASCII characters (!!!) and that IBM will move soon to a 9bit
byte (referencing their tape format).
Another issue where a choice may
have proven incorrect was the selection of the IBM CKD
format for discs. It was incorrectly believed that the
discs controllers could relieve the CPU from "search on
key" operations and lead to a better overall
performance of the system. It was incorrectly assumed that
one controller per disc drive was quite close to emerge. It
was also planned to have a media interchange at discpack
level with IBM, and that has been actually implemented for
the 2314 DOS format. That external specification, obviously,
lead to the choice of a CKD format.
Furthermore, the MSC designers "improved" the IBM
format in the direction of more sophistication like the
multi-track operations and the "SEARCH on DATA "operation
that, happily, was never used by the software.
Anyway, both Level1 and Level2 went to CKD and were not able
to completely get rid of it.
The choice of the IBM VTOC format, however, allowed Level 2
to get a more reliable interchangeable media support than
GCOS3 or MULTICS had . That peculiarity was extremely
precious in the debugging of software on several systems.
During this period, Marketing was
complaining about the wasting of memory that was the
consequence of a new operating system. Marketing was still
requesting a 64K system at a time where it was only possible
to have a GCOS64 --the eventual name of NPL OS Level2,
running in 256KB! A kludge solution of "hidden memory"
was invented in 1974 to let the customer believing that he
had only the sold 64K(and delivered 512K)!
The initial target of the NPL OS was
directed toward a batch environment like its predecessors
H2000 and GE100. The data communications applications
architecture was still really fuzzy. Boston responsibles
were sticking to the specifications of the proposed CTG
COBOL standard were ignoring either the emerging existence
of networks or the use of anything but a single COBOL
programmed set of applications per system was envisioned.
All responsibility for DC was under the CTG application
programmer who sometimes was surprised by the response time
of the RECEIVE/SORT/SEND sequence!
Time sharing applications à la
MULTICS or à la GCOS3 TSS had been ruled out by Marketing
and Management. The Transactional environment was not yet
planned but was considered as being an architectural
constraint that set up multi-processes J (process-group) and
the reserve of type-1 segments.
Program preparation was very
classical. COBOL was to be the primary language for
NPL. The compiler design in Boston was under the
responsibility of Ron HAM, later in DEC and then the
chairman of ANSI Programming Languages Committee.
PL/1 was being de- emphasized
and it was decided not to target the implementation of its
relatively exotic facilities such as dynamic tasking (the
future FORKing) nor to optimize on its dynamic type
conversions. In fact, some interior decor features, like
typed data descriptors, had such a support in mind. But,
when compilers did not take advantage of them and because
their performance cost in firmware, they were abandoned
before being put in use.
It was also initially planned to
provide early a "Descriptor access method" to
provide data type independence between programs and the
contents of files. But, this sub-schema implementation was
so delayed --until late 1980s, that the initial work on that
was practically scrapped. The definition of the language
processors and of their run-time environment was dominated
by the need for adherence to standards that causes many
controversies in the area of CALL/CANCEL verbs: did the
compliance to standards imply dynamic linkage of procedures?
Honeywell had, at this time, several standards gurus in its
organization and the gurus' answer was finally negative:
static linker could comply with the standard.
After resolving those controversies,
the end result was finally that GCOS64 was able to present
one compile-unit format common to all languages (Note,
however, that BASIC and APL, nor obviously LISP were not
contemplated at that time), that was something that IBM was
unable to get in S/360-370 and that GCOS8 is still
struggling to get close. A Linker able to
process those compile-units even in a multi-thread ( process)
environment was designed by Claude MASSUARD and is still in
use to day, although its design was one of the major issue
raised in Paris in 1972-1973. The number of segments
was already considered as a scarce resource and a
"binder" capable to merge several compile units in
one segment was designed in Boston essentially to maintain
the operating system modularity while economizing the number
of segments. The Loader, designed by Xavier
STEFANI, had the primary responsibility to link the
pre-linked load modules with the operating systems entry
points and to allocate virtual memory addresses to the
segments of the program.
The design and the development of
NPL Level2 software started initially using MULTICS and a
simulator operating -- very slowly, on Boston MULTICS
initially. The first original prototype was available on
April 1st, 1972 and a primitive, memory resident, operating
system, the SCP, was almost ready to be tested on it.
The P7 Prototype
The initial prototype was built in
Paris with parts manufactured in Angers and in Saint-Ouen.
It was installed in salle MAP at Gambetta. It consisted into
a CPU, a 128KB magnetic core memory --which was later
replaced by a 1Kb semiconductor storage, a Unit Record
Processor with a card reader, a PR71 line printer and a
Terminet TTY like console. The service processor functions
to be handled by the URC were not yet available and LED
panels and switches had to be used for kernel and firmware
debugging. The responsible persons for the CPU developments
were Georges LEPICARD and Jacques BIENVENU. The responsible
persons for the URC were Henri VERDIER and Gerard De PONCINS.
The debugging on actual hardware
needed synchronized updates of the Assembler made by Boston
team and a daily shipping of a card pack from Boston where
the compile/ link/ load process took place to Paris where
the prototype was being debugged. Surprisingly, this
distributed effort lead to one batch run per day,
complemented by firmware and software patches, which was
very closed to then prevailing standard for software
debugging. A back-up assembly was also being made on the
GE635 factory and management required that simultaneous
updates of both factories and program libraries be
maintained. By the end of June, at the price of an enormous
amount of over time, particularly by Jean Paul MESNAGE the
responsible of SCP, this basic operating system was debugged
and the prototypes could be operated by T&D development
people, peripheral controllers connection and software
Additional prototypes were built:
one was shipped to Billerica to complement the debugging of
tape and disc controllers that have been preliminary
debugged on a PSI simulator. A prototype was also shipped to
NEC, but this one did never reached Japan: it was burnt in a
747 sabotage in Benghasi in July 1973.
The bootstrapping of the initial
parts of GCOS64 nucleus was made from the SCP that operated
as a loader and debugging tool for the different modules of
A similar approach was taken for the
development and the debugging of the G100 emulator, but for
GE645 capacity reasons as well as for some hereabove noted
parochial reasons, the development was made on the GE635
factory. The H200 emulator was developed in Boston, under
the efficient management of the late Maria WELLER and used
more extensively the GE645 factory. It started also from the
SCP and later switched to another Boston environment (see
The Performances measurements
started without to many tools: a hardware monitor was
included only in 1973. The "measure" used for
system comparisons at that time was "Business Gibson
Mix" a computation of instructions times oriented on
character strings and similar to the scientific Gibson Mix
then in use in the industry Software overhead was ignored as
was ignored the efficiency of the compilers. HPL language
performances were not very satisfactory and the decision to
code the nucleus in Assembler appeared to be a reasonable
decision considering the time needed to get good
performances from HLL compilers. Later, performances
measurements tools initially designed by Phoenix were
introduced in NPL, especially PCMix that included software
compilers and run- time efficiency.
The Specifications of NPL Level2
were challenged from two sides: Product Planning people,
especially in Paris, found that it was too ambitious for a
G100 batch replacement and that it should be closer to
DOS/VS than to try to match OS/VS or some MULTICS
functionalities. A proposal was made at that time in Paris
to drop the development in favor of what was still a paper
OS, named SSS, planned to be developed from SCP by the G100
emulator team. On the other side, and especially in Boston,
it was argued that the software was not ambitious enough in
terms of dynamic resources management and that it had been
erroneous to drop the level 2B nucleus at the profit of
The Paris team had also to face a
tremendous staffing problem: in 1972, all software available
persons have been put on board of GCOS64. A frantic hiring
of new people was made to increase the number of developers
from around 50 to more than 180. Almost no turn-around of
personal was noticeable during this period. However,
difficulties of the working conditions (a high overtime --up
to a week of 60 hours, the lack of GE645 time, of prototype
time caused some social unrest at that time.
The Difficulties of 1973
The difficulties of the development
lead to a management crisis at the end of 1972. It
was seen unlikely that NPL Level2 was able to reach the
market at the end of 1973 as originally planned by Upper
Management --less than 3 years of design and development. Jean
BELLEC was replaced by Claude CARRE as the
responsible for development in Paris. The software
organization of Hardware engineering was merged into the
Software development organization. At the same period (early
1973), Georges LEPICARD who has been one of the key
architect of the NPL left the company to head the scientific
direction of CII. He will return in 1976 after the merger
between Honeywell Bull and CII to lead the "Leo"
project that was marketed as DPS-7/80.
The 4A Back-up
A contingency secret plan for a
Back-up was established in Boston; it was unveiled only in
its support of H200 emulator. This project named as 4A
Back-up was managed by William HEFFNER an original GCOS3
designer, who later left to DEC to become VMS manager.
This OS differed from Bull Level 2
design by a more interactive operation: one process per
"user" and by a simpler and less effective virtual
memory management: let the space per user increase and flush
the address space in case of overflow conflicts. This system
used the same compilers as Level2 and the "competition"
period had an 8 months' duration.
End of P8 Project
Ugo GAGLIARDI, by April 73, had to
step down from direct Boston (BCO) responsibilities which
were taken by Walker DIX who then cumulated the engineering
responsibility of Phoenix --then being reborn of its ashes,
and of Billerica.
The P8 Project was cancelled, at the
best pleasure of Paris hardware designers. In fact, P8 did
not show enough performance advantages from P7 from which it
differs not by technology, nor by the word length, but only
by a cache memory and better scientific performances. That
machine did not implement multi-processor, although this was
The NPL Technical Office was
dispossessed from program management responsibilities and
assigned to the technical cooperation between the HISI
project (level 62), the Bull Level 64 project and the
Phoenix Level 66 development.
John WEILL head of the Research
Center was given the responsibility of the overall project
coordination and he appointed William FRINK to insure Level
64 software coordination. Ernie DIETERICH, with Michel
ROCHER as an assistant, was later assigned to Paris to
manage the GCOS-64 plans.
The Series 60 Computational Theater.
The NPL Technical Office was then
involved in a frantic search of a common image to be
given to the then planned Series60 computers that
would cover in a single announcement:
- the Level 61 system --a Bull low
end product, essentially a re-announcement of GE58,
- the Level 62 system developed by
HIS Italia as the low-end of NPL,
- the Level 64system --alias
- the Level 66 system which was
essentially a re-announcement of the H6000 system.
A lot of work was spent in task
forces to try to achieve a common external visibility in
terms of programming languages, data bases organization, job
control language and operator interfaces. It was actually a
task analogous to IBM SAA 15 years later.
Formidable obstacles reside in the architecture
differences between Level 66 with its 36-bit data types
--with 6-bit and 9-bit characters, as well as ASCII
characters - present in Level 61 and 66- versus EBCDIC in
Level 62 and Level 64. Some "compromises" were
made by Level 64 to be closer to Level 66, in particular on
JCL and cataloging mechanisms.
The specifications of the, then
emerging Level 64 TDS were accepting the then current specs
of Level 66 TDS and emerging DMIV-TP, sometimes at some
expense of functionalities.
Although the Level 64 was considered
as a better vehicle for the out of base market, software
functionalities lagged significantly behind IBM's or Level
66. Also, some intense lobbying occurred to demonstrate that
IBM was just to scrap 370 at the profit of the
"FS", and that, consequently, the level 64 was
likely to compete with 370 at the time it would become
An attempt to have a common assembly
language between Level 62 and Level 64 failed on the
differences in Operating system calls. Italians who had a
target of Level 61 takeover, were not accepting the
unification on the UFAS basis and developed their own data
organization which was a superset of IBM System 3 and of
Level 61 including an ESDS organization and chains of "complementary
records". This organization was later introduced in
GCOS 64 as MLDS.
Those efforts were developed under
the name of "computational theater", a name
coined by John WEILL who played an important role in this
period. The majority of the technical energy was spent to
"give a common image" and to facilitate migration
whereas it was sure that the requirements for coexistence
were very few at a time where distributed systems and
communication networks were still in their infancy. Nobody,
however, in any organization was thinking seriously about
moving a customer from a Level to another one: each parish
actually planned to move up with its lot of customers.
The coordination made by the NPL
technical Office, and particularly by Gerald CLANCY and Ugo
GAGLIARDI was not involved in the decision process of the
implementation shops and was unable to make approved
anything but "common subsets" of the different
implementations. The laxity of "industry
standards" including ISO and ANSI standards authorized
many "implementer defined" features in conjunction
with contradictory "default" options. A lot of
energy was spent defining "common default" options
in COBOL, FORTRAN and RPG. From this experience, it should
be remember that a computation theater cannot be based on
existing applications when those applications take benefit
of machine specific features, such as physical
representation of objects and of specific hardware or
operating system features. It would be possible to specify
common products portable on different environments at the
condition that the initial ports be made by a single team.
A decision was made to merge
Engineering operations of Phoenix and Boston under Walker
DIX with the goal of increasing their synergy. Among the
assets imported from NPL to H-6000 were the COBOL-74
compiler written in HPL and which was converted to GCOS-III
via a PL/1 compiler.
|Priority to Level
Some Honeywell management views,
however, implied a phase- out of Level 64 at the profit of
Level 66 as soon as the G100 and H2000 business sources
would have dried up.
Consequences in Japan
It should be noted that the
Honeywell takeover of GE operations was not without
consequences in Japan. The TOSHIBA company had a long
relationship with GE and was a licensee of GE600 and GE6000,
while Nippon Electric (NEC) was a Honeywell licensee for
H2000. The Japanese Ministry of Industry and Trade (MITI)
pressed the two separate companies to work together and that
lead to a progressive takeover of TOSHIBA computer
(mainframes) operations by NEC.
Honeywell signed up with NEC a 10
years' know-how transfer agreement giving to NEC a full
access to NPL. All NEC current mainframe products -- ACOS2,
ACOS4, ACOS6 and later MS (Level 6) products -- are
born under this know-how agreement.
NEC acquired that know-how not only
by buying documents but also by sending contributors in the
Honeywell teams who were working on NPL as well as on
H6000--the new name of GE6000-. For example, Y.UMEMURA was
involved in H2000 to Level2 emulator and conversion team in
Boston. Y.TSUJI, H.SHIN were staying for several years in
Paris to work as programmers and later as coordinators of
the know-how transfer. K.NISHIMURA was also involved in the
manufacturing "dossier" technology transfer in
Paris and Angers.
A conflict occurred around 1974
between NEC and Honeywell. NEC had actually decided to make
Level 64 -- alias ACOS4, its primary product line. NEC
seemed to have taken this position because Level 64 was
locating itself in a 32-bits EBCDIC world which was the
world of Japanese big customers and also because the old NEC
establishment was very reluctant to unite with TOSHIBA
designers who had worked for long with GE on the GE6000
product line. Those differences inside NEC vanish
progressively because NEC management succeeded to have a
common organization for ACOS4 and ACOS6 product lines with
the only exception of the Basic Software Divisions.
Nevertheless, Honeywell forced Bull to cancel a new hardware
project the P7A, an ECL machine adding a paging
architecture to the original 64, which was planned to be
developed in Paris in common with NEC in 1973.
Honeywell put also a lot of pressure
on NEC to involve it in a new GCOS66 project called the
Med-6 project . NEC accepted to work on Med-6, and, for
instance, Yoishi UMEMURA was transferred from Boston to
Phoenix on this project. NEC invested later into the
ill-fated Med-6 using CML and water-cooled technology that
was announced by Honeywell as 66/85 and was later abandoned
when it was facing performance problems. This design
was still imported in Japan without water-cooling and was
the ACOS S/800, running under ACOS6. In the mean time, NEC
did not abandon any of its developments on ACOS4 and even
decided in the early 80s to let this product line
overlapping completely the ACOS6 product line.
L66 and Multics
In 1972, it had been decided that
the migration path out of the limited decor of the GE600
should be through the MULTICS decor that gave to the 36-bit
world similar advanced functionalities as Level 64, for
segment-level protection and high-level language support.
A coexistence through a GCOS3
accommodation mode under MULTICS, the development of a
transaction system à la Level 64 TDS on MULTICS decor and
the outstanding capabilities of MULTICS interactive
facilities - given enough hardware power- would have made a
more than reasonable product in 1974. It was also planned to
implement a virtual machine project on this system that
might have allow a future co- existence of a 32-bit world
with a 36-bit world. It was also planned and eventually
implemented to have a H2000 emulator on the Level 66, but
this was provided by the reconnection of a used H2000 to the
Level 66 system controller and did not imply access to the
The work based on MULTICS decor was
a little bit late - like the other NPL projects at the
exception of Level 62- and W.DIX finally endorsed a proposal
of John COULEUR, the original designer of GE600 and GE645
hardware, to introduce a new decor -called NSA as New
Six thousand Architecture- instead of following the MULTICS
roadmap. The new decor was considering segmentation as data
set descriptors and introduced address space as the
inter-user protection mechanism; the "ring"
concept was dropped for a "domain" mechanism that
potentially would avoid the "Trojan Horse"
syndrome of user data violation of privacy by procedures
planted in the system by some dishonest programmers; it also
introduced a progress over NPL implementation: it offered a
hardware controlled stack independent from software
controlled stack to store registers and return information.
This new decor was allegedly to be field retrofittable on
existing systems, which was eventually found not feasible,
and justified a delay to implement the new facilities. The
decision was fought desperately by MULTICS supporters, but
Marketing and Management were not clever enough to
appreciate the consequences of that decision.
It is not here the purpose of
telling the history of GCOS8, but it has to remember that it
took 6 additional years to be introduced and that the
unification of the segmented environments remains to be seen
14 years later.
Birth of NML future Level 6
At the end of 1973, Boston Computer
Operations had been completely re-oriented toward a
mini-computer project, called NML -as New Minicomputer Line-
which gave birth to the Level 6, later DPS-6, products. It
ought to be a competitor for DEC PDP-11 product and feature
a processor on one card. Part of the BCO staff was disbanded:
some move back to Phoenix and were there using their
experience in NPL to make the GCOS8 project rolling out;
other left to DEC where they were instrumental in the VAX/VMS
project; the majority move to the Level 6 project specially
in the area of compilers and utilities.
Conclusion of the first
That marked the end
of GCOS64 as a multinational project...
The reasons for success in this perilous
enterprise may be traced:
to the pugnacity of Bull manager, Marc
to the straightforward characteristics of a
large part of the design,
to the lack of alternatives offered to the
and –may be- to the permanent presence of
"enemies" external to the development team but
internal to the companies.
The areas of failures were:
an insufficient analysis of the market in the
areas of on- line processing and mini-computers,
the refusal to display the system
characteristics to customers and educational facilities,
the absence of conscience of the engineering
cost implied by some detailed design decisions - measurements
being done only on marginal manufacturing shop-costs,
a quite monolithic design of the software,
failing to offer the appropriate hooks for applications
non-provided by the producer.