INTERACTIVE MODES OF OPERATION | ||
Initial deliveries
of GCOS systems were for batch processing operation that was the main objective of
business data processing served by Honeywell and Honeywell-Bull. Engineers by designing
the above features have been objected that they were more ambitious than the market
required. However the market changed progressively during the 1970s. The traditional
way of planned batch processing was to be replaced by real time transaction processing.
Such a change was already perceptible in the mid 1960s, but had been matched with ad-hoc
solutions on systems like GE-400 or 600 and IBM S/360. The challenge was to incorporate
those new requirements in a general-purpose operating system. Interactive
Operator Facility Around 1980, there
was a requirement to build limited "time-sharing" facilities within GCOS.
The goal was essentially to provide interactive debugging facilities to programmers and
also to port some large applications needing interactions. There were alternative
solutions to the one what was chosen. TDS subsystem was already available, but the nature
of TP operations was specific and too restrictive: specific programming conventions,
limited working set of TP's etc. Building a new subsystem has already done with IBM TSO or
GCOS III TSS. It was preferred to extent the operator facilities and the JCL to build the
interactive facilities and use the standard system for the rest of the environment
(programming facilities, dispatching...) So the IOF environment could flexible ad
infinitum (almost). The architectural
implementation was to allocate a process group (one J) per user and spin-off J as
required. The total number of J was limited to 255, that number being an architectural
limit to the number of IOF users. Later slight modifications to the architecture
introduced by Japanese remove somewhat that limitations. Anyway, the number of IOF users
rarely exceeded 10 on a GCOS7 system. JCL that already
had some powerful capabilities was extended to be used interactively and renamed GCL
(generalized control language) and facilities built-in JCL but what had been of limited
use (for GCOSes compatibility reasons) were revived, giving to GCL most of capabilities of
a shell language. However, the heritage of a batch language restricted the primitives to
the commands already available. Instead of developing features like regular expressions
and pipes, it was chosen to augment GCL by a MENU processor offering a formatted menu to
the user and including default-options for most of the parameters. The Menu processor was
run in a listener thread allocated to each display terminal. That thread passed a GCL
stream for interpretation by the job scheduler server; if the GCL included the launching
of an interpreting processor, such as the editor or BASIC, or an user interactive program,
the remote terminal was allocated to that processor until its termination. IOF keeps
listening for a BREAK signal that could interrupt the operation of the interactive program
if the operator wished to get out from a loop or another faulty behavior. Another layer was
added to the console mode of IOF operation, initially available. It was a menu
handler based on VIP display alphanumeric terminals and allowing application programmer to
modify the terminal interface. A default system menu was substituted to the command
interface. IOF was the
environment for several programming languages: BASIC, APL. The environment of those
languages was quite different from standard programming languages. There was an
interactive editor/parser followed that spun off an execution job step (the byte code
interpreter). IOF was used also
with an text editor used essentially for entering programming languages source code and
the documentation (the latter during the period where PCs were not yet a common toll (in
the early 1980s). The editor was complemented by a formatter named WordPro that
work in a way similar to troff. Although, Bull
made an extensive usage of IOF for developing HPL programs for GCOS itself, specific
languages processors were developed for IOF. Most of them featured an interpretive
execution. IOF lacks the
interactive features invented in workstations and X-Windows became popular too late to
have influenced GCOS operating system. GCOS never lad and would have been to be deeply
modified to be a windows systems. The market of GCOS after having been in batch processing
definitively moved to a role of data base / transaction processing server.- Transaction Driven
System The basic
architectural constructs of GCOS were not directly matching the requirements of
transaction processing. The number of terminals (several thousands) connected to such an
application were to excess the architectural dimensions. The overhead implied by the basic
GCOS model (i.e. associating a job step to each transaction) had already proven
unacceptable in GCOS III TP-II. The TDS
Transaction Driven System model was gather a library of application specific commands that
could be "called" by users (almost exclusively clerks dialoguing with their own
customers by telephone or at a office window). The eventual purpose of those commands was
to update databases and/optionally to deliver a printed ticket and receipt to the
customer. The database was use to retrieve information, to create new information records
and to update existing data. Frequently, in addition to the dialog with on-line customers,
other transactions or printouts could be triggered following thresholds recorded on the
database, or on timing events. The transaction commands were named TPR Transaction
Processing Routines. They were stored in binary format as shared modules in a
library. The working area
of the transaction thread was the stack, but in addition some data segments (protected by
their read-only status or by semaphores) could be specified by the programmer. A TPR could
SEND/RECEIVE additional messages to the clerk and could accessed one or several records of
one or several databases. There was no specific restriction in data base usage and several
access methods could be used in a transaction. The TPR however should issue COMMITment
statements when it was ready to free the databases and must TERMINATE in relinquishing all
other resources not stored in the file system. TDS uses the GCOS
mechanism in mapping its own architecture concepts on the GCOS mechanisms.
Although, the
initial specifications called for a single TDS subsystem in a GCOS system, there was no
barrier to operate several systems with the same or different databases with the same or
different access rights in the same system. When DSA was
introduced in the early 1980s, the following options were taken for transaction
processing. Terminals not attended by clerks were not connected to the network. Attended
terminals had an open session to the TDS server after the clerk had logged-in and was
recognized by its terminal-id and its password. The network processor had no knowledge of
the transaction concept and was totally transparent to the transaction protocols and
commitments. In the mid 1980s,
transactions that could be distributed between different TP systems were
introduced using CTP -cooperative transaction processing- protocol closely
mapped on IBM SNA LU-6.2 (using DSA or DSA mapped SNA networks). Distributed TP between
GCOS TDS and IBM CICS was becoming a reality. A common
characteristic of the TP model exemplified by TDS was that the transaction system kept the
state of the whole transaction on behalf of the users. This was an heritage of the era of
dumb terminals (Teletypes and display terminals without programming capability). When PCs
were substituted to those dumb terminals, it subsisted a lack of confidence to store
enterprise level important data in the memory of PCs. There were many customers that
jeopardize the integrity of their databases by moving unconsciously to the client-server
model where the state of the transactions was distributed, partly in the user workstations
partly in the server (s). The centralized state model (in conjunction with CTP protocols)
was rugged and robust, however, it presented a bottleneck when a transaction processing
application became open to millions of Internet users. It also had problems to accommodate
very long duration transactions or hierarchies of transactions. Data Base server While Data
Management has been handled as a service operating in the thread environment of its caller
(the TDS threads for transaction processing), the port of Oracle by Bull engineers in the
early 1980s mark a change in the architecture. Essentially, to minimize changes in Oracle
source code, Oracle port was implemented as a separate J server (a specialized process
group) receiving SQL request from other client process groups (batch, IOF or TDS). Those
implementations were helping the introduction of a large number of processors. The Auriga
hardware architecture was characterized by sharing a L2 cache within a group of 4
processors. While that feature was masked to programmers and to the users, it has a
significant performances impact introducing a degradation due to the address space
migration between L2 caches. In the mid-1990s, GCOS systems were sold in attributing a
different price to the processors, decreasing the price for more computation incentive
applications such as Oracle and Buffer management servers, keeping them high for standard
GCOS applications. Open 7 System
Facility (UNIX environment) From 1975 to 1982,
GCOS was THE operating system of CII-Honeywell-Bull and its responsible had a tendency to
ignore two important factors that will change the world of software: the advent of the
Personal Computer and the penetration of UNIX an operating system developed essentially
outside the industry in non-profit organizations. The new Bull management was not at all
biased in favor of CII-HB product lines and attempted to convert the companies to the
world of Open Systems. It became obvious that opening the world of GCOS software would
allow to integrate new applications at a low cost, specially those developed for a direct
interaction of the user and his (or her) program. The IOF environment required a high
porting cost for applications developers who had develop them in mini-computer environment
or other incompatible systems. Several solutions
to offer a UNIX compatible environment were considered: a software solution and a hardware
solution where a UNIX supported processor such as Motorola 68000 would have been attached
to the GCOS system, as the DPS-6 Front-end processor has already been. The hardware
solution raises the issue of providing scalability across the whole range of DPS-7000. Its
implementation was initiated in the early 1990s on GCOS-8 systems and was adopted only in
the late 1990s on GCOS7 (Diane project). In fact it was a
port of UNIX to the DPS-7000 instruction set. This was done using the GNU C compiler with
the DPS-7000 assembler, generating native code. The UNIX supervisor ported to the native
decor was linked to service function that were calls to the GCOS services providing an
access to the UNIX resources files AND to the GCOS resources. This port of UNIX was
multi-threaded using the micro-kernel support and could take advantage from the DPS-7000
multi-processor, not only to have UNIX and GCOS coexist, but even to run simultaneously
several UNIX processes. Open 7, as the
UNIX port was called, used the services of GCOS operating system as emulators did, sharing
devices and system resources (timer, input and output). GCOS allocated to Unix a large
GCOS file that was mounted as a UNIX file system. All devices I/O were handled by GCOS.
UNIX benefited from the shared buffer pool of GCOS and did not need its own
peripheral. When it was
planned -around 1995-to discontinue the manufacturing of more performing DPS-7000
processor, this software solution lost its interest and a return to the hardware solution
was re-envisioned, using the Intel platform instead of the IBM/Motorola's one. The TCP/IP
stack was moved to the native GCOS and was the base of the interconnection of the two
worlds (by RPC instead of direct calls a sit was the case in Open 7). Finally a DPS-7000
emulator (Diane 2) was developed on IA-32 and IA-64 hardware architectures. Windows NT was
used as a loader and a supervisor for the GCOS applications that finally stayed with most
of GCOS code on top of the most popular architecture.
|
© 2001-2003 Jean Bellec