the GCOS 64 / GCOS 7 system

I/O Subsystems


The basis of Input and Output processing is performed in the channel processors. Channel threads are known as "execution of channel programs". The "decor" of the channels is an extension of the channel programming of the S/360 allowing for command chaining, data transfer chaining and signaling semaphores during and at the end of the execution of the channel thread. The work of the channel is coordinated with the operation of Peripheral processors that are themselves controlling the device electronics.

dps7000_io.gif (5622 octets)
I/0 subsystems architecture

Device electronics is usually developed by the device manufacturer for several product lines and use a "device common interface" (GCOS used for a while DLI –common to all Honeywell product lines- for tapes, discs and card equipments; later, industry standards were used such as SMD and SCSI). It is the role of the Peripheral Processor to give to software the architectured view. The Channels performs data transfer multiplexing and physical addresses resolution.

The level64 system implemented channels in time multiplexing the central processor hardware and channel threads were special real-time "micro-threads" of the micro-kernel. Later, on the DPS-7x0 and DPS-7000 models, the channels threads were executed in specialized I/O processors (each processor being time multiplexed between two physical channels). In some NEC high-end systems, the channel functions were split between in a very fast time-shared processor interfacing with main memory and slower processing units dealing with the physical channel. The peripheral control processors have many of functions of the device drivers and are specific minicomputers.

The I/O architecture presents another degree of complexity due to the fact that several devices (operating simultaneously or not) share the same physical link (case of SCSI devices or of terminal connected through a multi-drop interface). The architecture allows mapping devices on separate logical channels hiding to the programmer the way they are actually connected. The search of resilience (and sometimes of shorter latency time) lead to connect peripherals through several channels to the CPU. The architecture is also taking care of channels crossbars and is able (if not asked to have it visible) to hide the peculiarities of the configuration.

Honeywell and Bull produced several versions of PCPs, one of which –the communications front-end processor- being a standard level6 minicomputer. The other were either specially built around specific hardware data paths (then not achievable by standard minicomputers (e.g. the Billerica designed MSC mass storage controller, or built around specific architecture requirements (e.g. the URC unit record processor). Later PCP were implemented with standard microprocessor technology (usually MC-68000) and regrouped the channel functions with interface device functions.

Unit Record & Service Processor

The URP Unit Record Processor had a dual role of device control (Unit Record Controller) and of service processor. Its architecture was somewhat similar to the main CPU: it included a "micro-kernel" called micro-OS that handled interrupts and dispatched URC-micro-threads. Drivers micro-threads controls the URC devices (printer(s), card reader, cardpunch, paper tape reader/punch, magnetic tape cassette or 51/4 floppy disks…). Operator interface micro-thread handles at the command level interface the operator console: typewriter or the VDU (or the VDU emulator on PC –the latest avatar of the GCOS console). A specialized micro-thread is the service processor thread that in case of a central processor problem is able to take dump, to call the remote maintenance Field service and allows the remote field engineer to emulate the operator console. Actually, the service maintenance functions are executed through an interpreter of the byte code of a maintenance language that isolates the designer of maintenance procedures from the architecture of the service processor. It was not necessary to rewrite the processor maintenance code when moving from the URC to the MC68000 for the DPS-7000.

Before the introduction of a Level6 front-end processor, the communications lines were also handled by the URC, through a hardware byte multiplexer and a cluster of micro-threads called together the MLA Multi-Line Adapter.

At system initialization, the service processor also has the function to reset the other processors and to reload their firmware. The device threads required for initialization are partially in ROM, the service processors threads are on the floppy disk (originally on tape cassette) and the other peripheral devices are loaded from the central memory by the initialization program of the operating system (SIP).

It was originally contemplated to allow the user to program the peripheral processor. In fact, only the Communications adapter and the Document Handler were given programmer control independent from the operating system. The MLA used tables defined by the programmer to specify action from specific control characters and translating data encoding. The Document Handler required the real-time control of the sorter pockets according to data contents. A specific control language was designed and a translator generated binary code to be loaded dynamically in the URC and interpreted by the URP document handler micro-thread

.Storage Processors

Two distinct storage processors were designed at Billerica in 1971-1972, one for disks (Mass Storage Controller), the other for tapes (Magnetic Tape Controller).

The MSC (Mass Storage Controller) was controlling the IBM format "native" disks of the Level64, but also had to attach existing H-200  drives as well as GE-100 drives.

The MTC (Magnetic Tape Controller) was supporting 7-tracks and 9-tracks tapes. All existing formats 200, 556 and 800 bpi formats in NRZ and 800, 1600 bpi in PE (phase encoding) formats.

When, in 1976, the complete Level 64 project was transferred in Paris, repackaged versions of MSC and MTC were produced as MSC-E and MTC-E. Those versions were motivated to save space in cabinets and to get rid of obsolete circuit parts.

A new tape controller (ATP Advanced Tape Processor) designed to support the Belfort-produced GCR 6250bpi tapes (known as PENA-30) was designed by ex-CII peripheral engineers in 1978-1980.

Disks drives were produced initially by Honeywell own plants (Brighton MA, Oklahoma City, Heppenheim in Germany. Honeywell (and CII-HB) leave the disc peripheral business through a joint venture with Control Data (named MPI Magnetic Peripheral Incorporated). MPI strategy evolves progressively towards a production of industry standard devices (initially IBM compatible drives).
The Honeywell strategy had been, initially, to get rid of any plug compatible manufacturers and to develop its own device interfaces. Eventually, all the Bull and Honeywell product lines converted themselves to industry standards, sometimes through an intermediary version of industry standards.
A controller to support mini-computers SMD disks was developed as MSC-RV in the early 1980s for entry level DPS-7 systems.

A 68000 based controller to connect SCSI disks was developed for the entry-level DPS-7000.
With  SCSI disks, the physical format was changed to fixed sector format, a significant difference from IBM CKD format used as  native  from the early days of Level 64. As existing discpack were still supported, GCOS 7 was changed to support several disc architectures (at that time, support of IBM channel architecture was also planned. It was envisioned to connect  IBM discs subsystems;, through an interface developed jointly by IBM Poughkeepsie and Honeywell-Bull Phoenix for the DPS-8 product line in 1985. Business considerations -essentially their cost- aborted that attempt).
.The 68000 peripheral controllers were connected directly to the I/O bus of the DPS-7000 systems, making superfluous the PSI channel, except to previous existing subsystems. However, the PSI architecture was still emulated for software.

Eventually, the DPS-7 was connected to complete subsystems OEM bought from independent suppliers, such as Data General Clariion, StorageTek and EMC².

Communications Front End Processor

The communication between GCOS network software (FNPS) and the Level 6 (later a 68000 based "MainWay" processor) Datanet Network Software was implemented in a similar way. Datanet software is almost entirely common to GCOS7 and GCOS8 and supports pre-DSA, IBM SNA, DSA, ISO and TCP/IP protocols, the latter only in its "MainWay" incarnation.

The smaller models of GCOS64 systems received integrated, less expensive communications systems: MLA for primary networks of terminals, driven by the BTNS software. 
Later (1988), and for the same reasons, a 68000-based MICROFEP was able to reproduce a more compact version of  the DATANET on ARES systems. 

Pre-DSA includes supports character level terminals, BSC terminals and Honeywell specific VIP protocols.
SNA support allows GCOS access to IBM main frames and 3270-like terminals; it requires "presentation control" specific handling in GCOS7 applications.
DSA (Distributed Systems Architecture) was the main direction of CII-Honeywell Bull and Honeywell between 1975 and the early 80s. The DSA customer had over the SNA user the advantage of designing its network independently of its mainframes and the capability to coexist with SNA. DSA however was completely Honeywell and Bull proprietary and was not supported by independent terminal manufacturers.
Around 1985, Bull bet much hope (and much money) in the conversion from DSA to ISO that had been designed by committees where Bull was well (may be, too much) represented. ISO was quite similar to DSA, but however improved and different. This strategy collapsed in the 90s when it became obvious that TCP/IP happened to be  the de facto standard.
The TCP/IP support has been implemented in GCOS initially via the UNIX subsystem where was running the higher part of the TCP/IP stack interfacing the new front end processor that hosted the lower part of the stack. Eventually, in 1995, the upper layers were converted as native GCOS bypassing the overhead of the DSA to TCP conversion

Software handling of the I/O

GCOS architecture would have allowed to allocate directly a device to a user thread. However, many devices are shared between applications , in particular the discs units .So, the normal I/O operation for a thread is to pass to the shared Physical I/O module a logical device number (previously mapped on a logical volume –at open time-, and a template of channel program filled by segmented address of buffers, by a relative address inside the logical device. The logical channel program may contain several instructions as well as branches (local or even to another templates). Synchronously with the calling thread PI/O evaluates the absolute addresses in the channel programs and according the busy state of the logical channel allocated to the logical device either issue a connect instructions to the channel or queue the request to a logical device specific semaphore. When the channel program terminates another system thread (I/O Termination is notified that returns to the caller notification of the end of the channel program and dequeues the next request. The calling thread has the choice either to wait immediately on its I/O term semaphore or to do something else and to wait later. Intermediate or notification interrupts are notified by the channel thread on a separate semaphore to allow the handling of abnormal conditions in specific recovery procedures prior to notify the calling thread.

Although the architecture allows different termination semaphores on each logical channel, GCOS decided to use a single semaphore for ease of scheduling the I/O.

Some functions of GCOS did require a real time operation although less constraining. Disc management functions (ISAM search on key, data chaining, and ECC error reparation) and character level communications require performing software tasks without resetting the I/O operation. Character level communications were even more exotic because the micro-thread in the URC and the processing thread in the CPU were kept running continuously synchronizing themselves through semaphores until an administrative command (or some major errors) halted them.


  hardware     software  

Copyright © 1998 Jean Bellec and Fédération des Equipes Bull. Tous droits réservés.
Révision : 30 avril 2003