susceptibility occurrence of code. of the block to the invalid checking-block
Bits 16-23 ignored. of the The block tested is
contents of general contents of general ignored. addressed by register R 2 • register R1 the The are
When the storage-key 4K-byte-block
facility is not installed, all blocks
are double-key 4K-byte blocks, and two
keys are tested.
When the storage-key 4K-byte-block
facility is installed, all blocks are
single-key 4K-byte blocks, and only one
key is tested. In this instruction
definition, the term "storage keys" is used whether one or two storage keys are
affected.
A complete testing operation is neces­
sarily performed only when the initial
contents of general register 0 are zero.
The contents of general register 0 are
set to zero at the completion of the
operation.
If the block is found to be usable, the
4K bytes of the block are cleared to
zeros, the contents of the storage keys
are unpredictable, and condition code 0 is set. If the block is found to be
unusable, the data and the storage keys
are set, as far as is possible by the
model, to a value such that subsequent
fetches to the area do not cause a machine-check condition, and condition
code 1 is set.
The contents of general register R2 are
treated as a 31-bit real address of a
4K-byte block in storage. Bits 1-19 of
the register designate the 4K-byte
block, and bits 0 and 20-31 of the
register are ignored.
The address of the block is a real
address, and the accesses to the block
designated by the second-operand address
are not subject to key-controlled and
segment protection. Low-address
protection does apply. The operation is terminated on addressing and protection
exceptions. If termination occurs, the
condition code and the contents of
general register 0 are unpredictable.
The contents of the storage block and
its associated storage keys are not
changed when these exceptions occur.
Depending on the model, the test for
usability may be performed (1) byalter­
nately storing and reading out test
patterns to the data and storage keys in
the block or (2) by reference to an
internal record of the usability of the
blocks which are available in the
configuration, or (3) by using a combi­
nation of both mechanisms.
In models in which an internal record is used, the block is indicated as unusable
if a solid failure has been previously detected, or if intermittent failures in
the block have exceeded the threshold
implemented by the model. In such
models, depending on the criteria,
attempts to store mayor may not occur.
Thus, if block 0 is not usable, and no
store occurs, low-address protection may
or may not be indicated.
In models in which test patterns are used, TEST BLOCK may be interruptible.
When an interruption occurs after a unit
of operation, other than the last one, the condition code is unpredictable, and
the contents of general register 0 may
contain a record of the state of inter­
mediate steps. When execution is
resumed after an interruption, the
condition code is ignored, but the
contents of general register 0 may be
used to determine the resumption point.
If (1) TEST BLOCK is executed with an
initial value other than zero in general register 0, or (2) the interrupted
instruction is resumed after an inter­
ruption with a value in general register
o other than the value which was present
at the time of the interruption, or
(3) the block is accessed by another CPU or by a channel during the execution of the instruction, then the contents of
the storage block, its associated stor­
age keys, and general register 0 are
unpredictable, along with the resultant
condition-code setting.
Invalid checking-block-code errors
initially found in the block or encount­
ered during the test do not normally
result in machine-check conditions. The
test-block function is implemented in
such a way that the frequency of
machine-check interruptions due to the
instruction execution is not
significant. However, if, during the execution of TEST BLOCK for an unusable
block, that block is accessed by another CPU (or by a channel), error conditions
may be reported both to this CPU and to
the other CPU (or to the channel).
A serialization function is performed
before the block is accessed and again
after the operation is completed (or
partially completed).
The priority of the recognition of
exceptions and condition codes is shown
in the figure "Priority of Execution:
TEST BLOCK."
Resulting Condition Code:
o Block usable
1 Block not usable
2
3
Chapter 10. Control Instructions 10-51

Program Exceptions:
Addressing (fetch and store, oper­
and 2) Operation (if the test-block facil­
ity is not installed) Privileged operation
Protection (store, operand 2, low­
address protection only)
1.-6. Exceptions with the same pri­ ority as the priority of pro­
gram-interruption conditions
for the general case.
7.A Access exceptions for second
instruction halfword.
7.B Privileged-operation exception.
8. Addressing exception due to
block not being available in
the configuration.*
9.A Condition code 1, block not
usable.
9.B Protection exception due to
low-address protection.* 10. Condition code 0, block usable
and set to zeros.
Explanation: * The operation is terminated on
addressing and protection excep­
tions, and the condition code may
be unpredictable.
Priority of Execution: TEST BLOCK Programming Notes
1. The execution of TEST BLOCK on most
models is significantly slower than
that of the MOVE LONG instruction
with padding; therefore, the
instruction should not be used for
the normal case of clearing
storage.
2. The program should use TEST BLOCK at initial program loading and as
part of the vary-storage-online procedure to determine if blocks of
storage exist which should not be used.
3. The program should use TEST BLOCK when an uncorrected error is
reported in either the data or
storage keys of a block. This is
because in the execution of TEST BLOCK the attempt is made, as far 10-52 System/370 Principles of Operation as is possible on the model, to leave the contents of a block in a
state such that subsequent
prefetches or unintended references
to the block do not cause machine­
check conditions. The program may use the resulting condition code in
this case to determine if the block
can be reused. (The block could be
i ndi cated as usable if, for
example, the error were an
externally generated error or an
indirect storage error.) This
procedure should be followed
regardless of whether the
indirect-storage-error indication
is reported.
4. The model mayor may not be
successful in removing the errors
from a block when TEST BLOCK is executed. The program therefore
should take every reasonable precaution to avoid referencing an
unusable block. For example, the
program should not place the page­
frame real address of an unusable
block in an attached and valid
page-table entry.
5. On some models, machine checks may
be reported for a block even though the block is not referenced by the
program. When a machine check is
reported for a storage-key error in
a block which has been marked as
unusable by the program, it is
possible that SET STORAGE KEY or
SET STORAGE KEY EXTENDED may be
more effective than TEST BLOCK in
validating the storage key.
6. The storage-operand references for
TEST BLOCK may be multiple-access
references. (See the section "Storage-Operand Consistency" in Chapter 5, "Program Execution.") TEST PROTECTION TPROT [SSE] '---- __ ' E_50_1_' _--,-I_B_I ---IIL..-~ , I B 2 I ~:J o 16 20 32 36 47
The location designated by the first­ operand address is tested for protection
exceptions using the access key speci­
fied in bits 24-27 of the second-operand
address.
The second-operand address is not used
to address data; instead, bits 24-27 of
the address form the access key to be used in testing. Bits 8-23 and 28-31 of
the second-operand address are ignored.
The first-operand address is a logical
address and thus is subject to trans-