B5500/5700 Design Concepts
The current B5500/5700 hardware and software systems are the result of many years of evolutionary development under the Burroughs approach to computer system design. This approach is to totally integrate both hardware and software through a policy of cross-training the design specialists. Hardware engineers learn the intricacies of software architecture, and software specialists learn the subtleties of hardware logical design. These people are then merged into a single system design team.
Development and installation history
In the late 1950s, such a team produced the hardware and software design specifications for the Burroughs B5000 computer system. By 1962 the first B5000s were installed using the original software operating system called the Master Control Program (MCP). At this time the B5000 was used only for batch processing, the access mode for which it was designed. In 1965, the hardware configuration was expanded. The most significant change was the replacement of the auxiliary drum storage with disk storage. A revised operating system, called the Disk File Master Control Program (DFMCP), was supplied to utilize the new storage medium. Batch processing was still the only mode of access. At this time, Burroughs changed the name of the system from the B5000 to the B5500.
In 1966, the hardware configuration was again expanded. This time the most significant change was the addition of telephone interface equipment. A revised operating system, called the Data Communications Master Control Program (DCMCP), was supplied by Burroughs, to suppor the remote terminal access mode in addition to the usual batch processing. These events made available for the first time the new dimension of remote computing. The features of the original Master Control Program software were broad enough to require only a modest amount of alteration to produce DCMCP. Although the DCMCP permitted remote users to interact and converse with their programs, it treated remote jobs more or less teh same way it treated batch jobs. This caused some remote users to sit idle for extended periods of time before their jobs were initiated; however, once the job was initiated, the response time was usually satisfactory, psychologically, this left something to be desired. One solution developed for this problem was time slicing, or true time sharing.
The B5500 time sharing system, released in 1969, eliminated this inadequacy. The software operating system was modified and called the Time Sharing Master Control Program (TSMCP). Since both the DCMCP and the TSMCP evolved from the same design, they both contain the same important features of the original design, and they differ only in certain resource management strategies.
In 1970, Burroughs announced the availability of certain additional hardware for the B5500, such as extended core memory and a data communications processor. Newly installed B5500 systems with these hardware features are called B5700 systems. Subsequent to the B5700 announcement, some new Burroughs publications and several revisions to older manuals used the term B5700 in their titles. At the present time, all software and programmer reference manuals with either B5500 or B5700 in their titles are pertinent.
Design features
The original B5000 system contained many significant features, primarily as a result of the unified hardware and software design approach. All these original features are still present in the system as it now exists, although many changes and enhancements have been made in the interest of user convenience and operational efficiency. Some of the more significant features will be described rather briefly.
The Master Control Program (MCP)
One of the B5000 design objectives was a system capable of controlling its own resources and scheduling work on a dynamic basis. This was accomplished with the operating system software, originally called the Master Control Program, or MCP. Later, as significant capabilities were added to the MCP, it was called DFMCP, the DCMCP, and the TSMCP. The MCP is the controlling traffic director of the entire system. It always is in control of the hardware, or has the means of regaining control. Its main function is to permit the hardware to process all user jobs presented to it by the operator. Furthermore, it must perform all of the many, many tasks associated with job processing as efficiently as possible. To be efficient it must be cognizant of the resources available and the resources needed by each job, and be able to allocate and deallocate resources to the job stream as quickly as possible.
Hardware status monitoring
In many operating systems the available resources (hardware configuration) are specified as parameters when the software is assembled for loading (system generation). In such systems, if the hardware configuration should change either by adding more devices such as core memory, tape units, card readers, etc., or by removing some device, possibly for temporary maintenance, the operating system may require partial or complete regeneration. In Burroughs systems, the MCP continually checks the status of the total system. It maintains comprehensive but compact availability tables that indicate the number of tapes, disks, printers, I/O channels, and other devices which are available and ready. Changes in status are easily detected because of the high degree of hardware-software integration.
Fail-soft capability
This dynamic assessment of current resources permits a fail-soft capability; i.e, malfunctioning devices can be dynamically removed for maintenance and the system will continue to function. Of course, there are fewer resources and throughput may decrease, but, nevertheless, the machine will continue to function. A memory module, an I/O channel, a peripheral device, or even a central processor in a two processor system, can be taken off-line and the MCP will reroute the work around the missing components; certain devices may even be removed while the system is operating without causing a system failure.
Dynamic resource management
Provided with up-to-date resource availability tables, the MCP is able to dynamically assign certain resources to a particular user job. Rather than, at job initiation time, assigning all resources that will ever be needed, specific resources are dynamically assigned and deassigned to each job as required. This dynamic assignment is accomplished not only for peripheral devices such as tapes, printers etc., but also for the floating I/O channels and main core memory. This means that only that portion of main memory (the most expensive resource) which actually required at that instant is ever assigned to a job.
Multiprogramming and multiprocessing
Because most jobs require only a portion of the total system at any given instant (especially core memory), the MCP is able to initiate several jobs concurrently and assign them disjoint sets of resources. With only one or two central processors, only one or two jobs "in the mix" may be in execution at any given instant; however, the processor(s) may be assigned to different active jobs during brief, disjoint intervals of time. This ability to have many jobs (or programs) concurrently active is called multiprogramming. If a system contains two or more central processors and is able to execute simultaneously a job in each process, it is said to be capable of both multiprocessing and multiprogramming. Furthermore, the sets of resources assigned to the active jobs need not be disjoint. Since assignments are made dynamically, they need only be disjoint with respect to time. This leads directly to the concept of "time-sharing" of resources, although the current discussion pertains to a feature of the batch processing MCP.
Automatic file recognition
A practical necessity of the multiprogramming MCP is the authority to make specific peripheral device assignments. A desirable consequence is that the programmer need not, in fact can not, make specific unit assignments. The programmer need only specify the type of device and then address all program and data files by name only, for example, if a program needs to create a tape file, the MCP assigns an available tape unit and thereafter associates that unit with the programmers choice of file name. Similarly, if a program requires some particular tape file for input, it is called by name only, the operator can mount the tape on any available unit and the MCP automatically recognizes the file name and makes the unit assignment.
Peripheral device independence
Automatic file recognition also facilitates the realization of true device independence. This permits magnetic tape and disk to be used as backup, pseudo-devices, for the card readers, line printers, and card punch. Instead of forcing a job to wait for access to a busy peripheral device, the MCP automatically assigns a temporary backup device. This feature provides a considerable increase in efficiency and throughput.
Homogeneous hardware architecture
The hardware architecture which makes multiprogramming and dynamic resource allocation practical is centred around two exchanges - the memory exchange and the input/output (I/O) exchange. Each central process can access any of the eight core memory modules through the memory exchange. Likewise any of the four floating I/O channels can access memory without interfering with the processors. In turn, the I/O channels can access any of the peripheral devices through the I/O exchange. Thus, both processors and all I/O channels could simultaneously access different modules of memory. The exchanges contain the logic necessary to float the access requests to a free I/O channel. Each I/O channel contains the logic and registers necessary to autonomously complete the information transfer once it has been initiated.
Typical B5700 configuration
A typical configuration is as follows:
1 Central processing unit
8 Core modules (4,096 words each)
3 Floating I/O channels
5 Magnetic tape units, 7-track, 200/556/800 BPI
5 Disk storage modules (1,200,000 words each)
2 Line printers (1100 lines per minute)
1 Card reader (1400 cards per minute)
1 Card punch (300 cards per minute)
1 Operator console (SPO)
16 Telephone line adapters and buffers
