suited for the attachment of buffered
devices and high-speed cyclic devices.
An individual System/370 installation is
obtained by selecting the system compo­
nents best suited to the applications
from a wide variety of alternatives in
internal performance, functional
ability, and input/output. COMPATIBILITY COMPATIBILITY AMONG SYSTEM/370 MODELS
Although systems operating in the System/370 mode may differ in implemen­
tation and physical capabilities, logically they are upward and downward
compatible. Compatibility provides for
simplicity in education, availability of
system backup, and ease in system
growth. Specifically, any program writ­
ten for the System/370 mode gives identical results on any system operat­
ing in that mode, provided that the
program:
1. Is not time-dependent.
2. Does not depend on system facili­
ties (such as storage capacity, I/O
equipment, or optional facilities) being present when the facilities
are not included in the configura­
tion.
3. Does not depend on system facili­
ties being absent when the facili­
ties are included in the
configuration. For example, the
program must not depend on inter­ ruptions caused by the use of
operation codes or command codes
that are not installed in some
models. Also, it must not use or
depend on fields associated with
uninstalled facilities. For exam­
ple, data should not be placed in
an area used by another model for
logout. Similarly, the program
must not use or depend on unas­
signed fields in machine formats
(control registers, instruction
formats, etc.) that are not explic­ itly made available for program
use.
4. Does not depend on results or func­
tions that are defined to be unpre­
dictable or model-dependent. This
includes the requirement that the
program should not depend on the
assignment of I/O addresses and CPU addresses.
5. Does not depend on results or func­ tions that are defined in the
functional-characteristics publica-
tion for a particular model to be
deviations from the architecture.
6. Takes into account those changes
made to the original System/370 architectural definition that
affect compatibility among System/370 models. These changes are described in Appendix I. COMPATIBILITY BETWEEN SYSTEM/360 AND SYSTEM/370 System/370 is forward-compatible from System/360. A program written for the System/360 operates on the System/370, provided that the program:
1. Complies with the limitations
described in the section "Compat­ ibility among System/370 Models."
2. Does not use PSW bit 12 as an ASCII bit (a special case of the second
rule in the section "Compatibility among System/370 Models"). 3. Does not use or depend on storage
locations assigned specifically for System/370, such as the
interruption-code areas, the
machine-check save areas, and the
extended-logout area (a special
case of the third rule in the
section "Compatibility among System/370 Models").
4. Takes into account other changes
made to the System/360 architec­
tural definition that affect
compatibility between System/360 and System/370. These changes are
described in Appendix H. Programming Note
This pUblication assigns meanings to
various operation codes, to bit posi­
tions in instructions, channel-command
words, registers, and table entries, and
to fixed locations in the low 512 bytes
of storage. Unless specifically noted, the remaining operation codes, bit posi­
tions, and low-storage locations are
reserved for future assignment to new
facilities and other extensions of the
architecture. (In addition to fixed
locations in the low 512 bytes, logical
location 795 is assigned to a specific function.)
To ensure that existing programs operate
if and when such new facilities are installed, programs should not depend on
an indication of an exception as a
result of invalid values that are currently defined as being checked. If
a value must be placed in unassigned Chapter 1. Introduction 1-3

positions that are not checked, the
program should enter zeros. When the
machine provides a code or field, the
program should take into account that
new codes and bits may be assigned in
the future. The program should not use
unassigned low-storage locations for
keeping information since these
locations may be assigned in the future
in such a way that the machine causes
this location to be changed. SYSTEM PROGRAM The system is designed to operate with a
control program that coordinates the use
of system resources and executes all I/O instructions, handles exceptional condi­ tions, and supervises scheduling and
execution of multiple programs. AVAILABILITY Availability is the capability of a
system to accept and successfully proc­
ess an individual job. System/370 permits substantial availability by
(1) allowing a large number and broad
range of jobs to be processed concur­
rently, thus making the system readily accessible to any particular job, and (2) limiting the effect of an error and identifying more precisely its cause, with the result that the number of jobs
affected by errors is minimized and the
correction of the errors facilitated. Several design aspects make this possi­
ble. • • A program is checked for the
correctness of instructions and
data as the program is executed, and program errors are indicated separate from equipment errors. Such checking and reporting assists
in locating failures and isolating
effects.
The protection facilities, in
conjunction with dynamic address
translation, permit the protection
of the contents of storage from
destruction or misuse caused by
erroneous or unauthorized storing
or fetching by a program. This provides increased security for the
user, thus permitting applications with different security require­ ments to be processed concurrently with other applications.
1-4 System/370 Principles of Operation • • • • • • • Dynamic address translation allows
isolation of one application from
another, still permitting them to
share common resources. Al so, it
permits the implementation of
virtual machines, which may be used
in the design and testing of new
versions of operating systems along
with the concurrent processing of
application programs. Addition­
ally, it provides for the
concurrent operation of incompat­ ible operating systems.
Multiprocessing and channel-set
switching permit better use of
storage and processing capabili­
ties, more direct communication
between CPUs, and duplication of
resources, thus aiding in the
continuation of system operation in
the event of machine failures. MONITOR CALL, program-event record­
ing, and the timing facilities
permit the testing and debugging of
programs without manual inter­
vention and with little effect on
the concurrent processing of other
programs.
Emulation is performed under
control-program superV1Slon, thus
making it possible to perform
emulation concurrently with other
applications. On most models, error checking and
correction (ECC) in main storage, CPU retry, and command retry
provide for circumventing intermit­
tent equipment malfunctions, thus
reducing the number of equipment
failures.
An enhanced machine-check handling
mechanism provides model­ independent fault isolation, which
reduces the number of programs
impacted by uncorrected errors.
Additionally, it provides model­
independent recording of machine­
status information. This leads to
greater machine-check handling
compatibility between models and
improves the capability for loading and operating a program on a different model when a system fail­
ure occurs.
A small number of manual controls
are required for basic system oper­
ation, permitting most operator­
system interaction to take place
via a unit operating as an I/O
device and thus reducing the possi­
bility of operator errors.