L64 and DPS7/7000 Storage Controllers

-incomplete-

Level 64 systems were to be configured with at lest a mandatory disc subsystem and an optional tape subsystem. As almost all system migrating to Level 64 were tape oriented, few disc only systems have been sold. The mass storage controllers evolved with time to support new devices and for cost reduction. Tape controllers evolved the same way. The introduction of a streaming tape connection to the URC in the early 1980s coincided with the abandon of removable discs on DPS-7

Attachment of new controllers was technically asynchronous with the introduction of new systems until the advent of DPS-7000 Ares phase 3 that initiated the evolution towards industry standard parts. Eventually complete subsystems ended to be sourced from independent manufacturers such as EMC.

DISC CONTROLLERS

The disc controllers were known under different acronyms in engineering and in the field. They have a very limited visibility in the field, some having been bound with the central processor in some cases. They have been called usually Mass Storage Processor emphasizing "distributed processing" as a distinctive Honeywell and Bull advertising feature.

MSC

Specifications

The original MSC was designed by Honeywell in Billerica in 1971-1972. It has to support state-of-the-art disc devices produced by Honeywell for the H-2000 product line and were, from the hardware point of view, clones of IBM 2314 and 3330 removable discs. The native mode of formatting had to be IBM variable CKD, allowing a data exchange for a migration from low-end S/360 systems. The IBM compatibility was extended to the file system (the IBM VTOC was also adopted)
In addition, the Honeywell H-200 fixed sector format had also to be supported for assisting in co-existence / migration with H-200/2000.
The combination of those requirements was a superset of the IBM disc subsystem architecture and the simultaneous support of several physical formats. A SEARCH DATA command was added to the SEARCH KEY with the believing that more and more data base functions will migrate closer to the physical device, a prediction that was not realized.
The GE-100 small removable drives also were attached to the MSC, but they were supported only by the GE-100 emulator and its special utilities. Their attachment was not raising specific constraints to the controller.

Supported devices

MSU-300

Architecture

The MSC was powered by a special processor optimized on byte searching and fast transfers from the DLI (device level interface) and the main memory (trough the PSI channel) and with a very limited amount of buffering inside the MSC.

The I/O architecture allowed "simultaneous" transfers on logical channels, i.e. block multiplexing. A single logical channel was allocated to each device, while it was contemplated to add fixed head devices that might have several partitions and one logical channel per partition.

The MSC was able to function in dual PSI mode; i.e. a couple of MSCs might be connected to up to 16 devices allowing a pool of 16 logical channels allocated transparently to software (except initialization and malfunction). Dual-PSI allowed dynamic file sharing between two independent GCOS systems, tanks to a software trick to implements shared locks between subsystems by writing a LOCKED status bit in the file entry inside the VTOC using an uninterruptable channel program performing a SENSE/SET if UNLOCKED chain of commands to the MSC. This feature with no hardware impact was known to customers as "coupled systems" feature.

The lack of buffer size in the MSC precluded the automatic recovery from data transfer errors. CRC was computed by the MSC but retries had to be performed by the operating system module (PIAR).

Technology

The MSC was implemented in the same technology as Level 64 (TTL 74N, SP10)

Tests and Diagnostics

The MSC was maintained with  a check-out program running under the free-standing operating system SCP and by functional tests (under SCP and later under GCOS). Those tests emphasized stress on transfer rates on one or several channels, but were not always able to anticipate real stress load caused by variations in CPU speed (creation of sub-models) or introduction of new formats.

MSC-E

The MSC project's maintenance was transferred from Billerica to Paris in 1973-1974. The most visible change was the discarding of 2314 family of disc pack and the support of larger discs. The MSC-E included cost-reduction features (denser memory, use of 74S technology, repackaging of card-cages). With MSC-E, coincided the transfer from Honeywell to MPI (a CDC joint venture) of the production of discs.

In addition to MSU-300, MSC-E supported non removable MSU-500 and MSU-555 fixed disks.

MSC-RV

MSC-RV was a complete reengineering of the MSC architecture by using a new processor (based on bit-sliced AMD processor) and the replacement of DLI disc drive interface for the more standard SMD interface. However, the paranoia against clones still subsist in Honeywell, the disc interface was a specially modified version of SMD named SMD-1 interface (also supported by DPS-4 and DPS-6). The discs connected to MSC-RV were MPI removable SMD 300, with a capacity of 300MB, while the SMD-80 (with 80MB per drive) connected to DPS-4 were also available for conversion purpose. SMD-80 were not available as a GCOS residency. They were only data and application discs.

MSC-RV differed functionally from MSC-E by the size of the volumes and by the restriction to a single CKD format.

MSC-H project

MSC-H was the code name for a project contemplated since he early 1980sthat was eventually discontinued. It would have supported fixed discs and tapes on the same subsystem, allowing off-line back-ups of disc files. The discs contemplated at the origin were CII developed Cynthia family used in fixed format. The cancellation of large capacity models and the eventual discontinuation of the Bull disc activity decreases the interest for the project. The specification of fixed sectors formatting needed a substantial software revamping that was not available until the second part of the 1980s and compromised the profitability of that project. A similar less ambitious project was  named (in 1981) MSC-RF but all those attempts were not successful.

MSC-4

The MSC-4 project differed from its predecessors by the integration of the controller (s) and of 8 in drives in the same cabinet. Instead of being sourced from a somewhat fledging MPI, the 500MB FSD-500 drives were sourced from Hitachi. A low-height cabinet was able to store up to 4 drives. The MSC-4 engine was a reimplementation of the MSC-RV engine.

MSC-4B

MSC-4B differed essentially from MSC-4 by introducing a PSI-S interface, a mode developed by NEC to increase the transfer rate on PSI. PSI-S was available on Aquila (from NEC origin), Ares phase 2 and Auriga. Acknowledgment signals were no more sent for each byte transfer to the IOC allowing to almost doubling the peak transfer rate.

Copernique project

Bull contracted with Copernique the realization of a high end subsystem with a distributed intelligence option as a development of the special realization of Copernique for the Level 6. Bull specified an interface expected to-be standard instead of the SCSI interface chosen by Copernique. The project was initiated in 1987. The device interface selected by Bull and Honeywell with Control Data was IPI-2 (Intelligent Peripheral Interface) instead of SCSI. Instead of IPI-3 interface used to support similar drives on DPS-8000, Bull was keeping the PSI connection

Eventually, the project (intended to be named APSS Advanced Peripheral Subsystem)was cancelled.

SCSI Controller on DPS-7000

When it was decided around 1985 to derive a low-cost version from the Ares system, it became obvious that its discs should use low cost competitive discs developed for the micro-computer industry. Simultaneously, Groupe Bull had chosen to use MC68000 as its choice microprocessor Multibus II as its small systems backbone. So, the connection of SCSI discs through a Multibus II was the base of the new storage subsystem for the Libra project developed around 1987-1988. A quest for an existing controller of this kind started, but Multibus II was not attractive to the OEM suppliers and it was eventually decided to work in cooperation with a British design company on such a subsystem. Bull had also developed an interconnect between Multibus II and DPS-7000 I/O bus that emulated the PSI channels software visibility. That board was used across the design of the new peripheral processors.
The SCSI discs were used with a fixed sector format (common to the microcomputer industry). Such format was already checked-out and was secure enough to avoid some of the burden found in the analog part of the device in first MSCs. It did not need the synchronization surfaces. A CKD emulation , such as that what made the success of EMC˛ later, was not adopted. So many components of GCOS 7 had to be revamped to support exclusively the new "fixed Sectors format". 

FIPS project

In the late 1990s, before plans for shelving off the extension of high range GCOS7 had materialized, it was contemplated to offer IBM or IBM compatible storage subsystems. A IBM channel adapter to the PSI channel had been realized by a joint work group between IBM Poughkeepsie and Bull-Phoenix. As few differences existed between PSI of DPS-7 and DPS-8000 product lines, this solution was prototyped on a DPS-7000 in Phoenix. But it was not introduced on the market.

 

EMC subsystems

In the mid 1990s, Bull renounced to build itself its own controllers and relied on external suppliers who had already penetrate the main frame market with subsystems, with RAID capability, based on microcomputer supplies. The same subsystems were offered on the UNIX product line and were also offered as Network Storage systems.

 

TAPE SUBSYSTEMS

MTC

The original MTC was designed in Billerica to support the collection of tapes available in 1970 in GE, Honeywell and across the industry. Two recording formats were available NRZI IBM formats in 7 or 9 tracks available in densities (200 bpi, 556 and 800 bpi) and PE (Phase encoding) format also introduced by IBM in 800 and 1600 bpi. Several logical formats had been introduced by GE and Honeywell in GE-100 and H-200 product lines . Level 62 and Level 64 used the IBM format (including labels) as the native format. Other formats were supported by utilities and by the emulators.
The physical format of the tapes (density and speed) had to be "guessed" by GCOS as part of the "automatic volume recognition" procedure, that freed the operator of mandatory mounting on a specific drive.

Although also designed in Billerica the MTC used a different engine from the MSC. That engine was optimized towards minimizing the start stop time and to perform efficiently data chaining across different zones of memory. The processor did recognize end of blocks characters and was able to perform on the fly code conversion.

Two MTC could be associated to an extended crossbar allowing 16 tape units to be connected to each controller.7-tracks tapes support was an extra-cost option.

The technology was Level 64 based (TTL 74N and S, SP10 small boards).

MTC was supported by a collection of maintenance tools specially developed in Billerica. In addition of functional tests available for SCP and transferred under GCOS by Paris engineering (in 1976-1977), a programmed maintenance panel (in fact an interpreter for a  single or a batch of hardware level commands) was made available (under SCP and GCOS). Tape devices analog hardware electronics was hardly visible through the DLI interface and functional tests preceded oscilloscope investigations.

MTC-E

When Paris engineering took over the project in 1974, a new cost-reduced version of MTC was developed for Level-64-DPS. It eliminated rarely selected  options, like 7 tracks support and NRZI. The controller engine was the same as MTC, simply reimplemented in 74S technology.

ATP

An "Advanced Tape controller" was designed to support 6250 bpi tapes with GCR format developed by CII prior the CII-HB merger. In addition to GCR tapes, ATP provided a 2x16 crossbar that could be either be used as a dual channel tape subsystem in a single system or being shared between two independent software system. Actually, P7G (alais Leo, DPS-7-82) in a dual processor configuration could be partitioned in two systems under GCOS7 and the Siris8 emulator. ATP was used in high performances members of DPS-7 lines during the 1990s in conjunction with PENA-30 tape drives.
The subsystem was initially developed in Les Clayes, but the maintenance of it was transferred in Belfort.

MTC-G

Magnetic Tapes Attachment on  URC-E (MTA)

Cartridge Tapes Libraries

Cartridge tapes became popular at the end of the 1980s and customers of DPS-7000 large systems required the connection of Masstor and StorageTek libraries. 

 

Back

Revision: 21 janv. 2002