DMKTRKIN is called only by DMKD1SER, which in turn is called only by DMKIOS. These three routines work closely together during alternate
track error recovery and the control flow back and forth between these
routines is controlled to a great degree by flags in the IOBLOK and the IOERBLOK. The control blocks of major concern in this area are the RDEVBLOK, the IOBLOK, and the IOERBLOK. When an error occurs and DMKIOS makes the
initial call to DMKD1SER (at the time of the first error associated with
this IOBLOK), an IOERBLOK containing sense data has already been
created; the IOBIOER field of the IOBLOK points to it. When D!KDASER gets control, it notices that this is a first call and it moves the
pointer out of IOBIOER into RDEVIOER so that this first IOERBLOK, associated with the original error, can be kept over a period of time during which attempts may be made to retry the I/O operation. Daring these retries, further errors may cause new IOERBLOKs, pointed to by IOBIOER, to be sent back from Generally RDEVIOER continues to point to the original IOERBLOK and new IOERBLOKs are
created and sent back from DMKIOS after each retry that ends with an
error. Generally, the new IOERBLOK from the failed retry is discarded
before the next retry. But occasionally a new IOERBLOK is used by DMKD1SER or DMKTRKIN to replace the original IOERBLOK, so it is pointed
to by RDEVIOER and the first original IOERBLOK is discarded before the
next retry. This happens when the new error is deemed to be more severe
than the original (DKKD1SER gives priority to channel checks) or when
the original error gets corrected by a retry, but then the channel
program fails on a later CCW (DMKTRKIN does this).
Control flow back and forth between DMKIOS and DMKD1SER is controlled by the setting of the flags IOBERP, IOBRSTRT, and IOBFITIL, and has been
described earlier in the section "D1SD Error Recovery, ERP (DftKDAS)." The control flow back and forth between D!KD1SER and DMKTRKIN is
controlled by the flags IOERRDRO and IOERALTR and by a return code that DKKTRKIN passes back in register 1. Whenever either of the two flags is
set, they cause DMKD1SER to call DMKTRKIN whenever DMKDASER gets control
(which in this case happens after a retry), even though there is no
track condition check indicated in the new IOERBLOK. The IOERRDRO flag
indicates to DKKTRKIN that the retry being returned from was used to
execute a channel program to read record zero. The IOERILTR flag
indicates to DKKTRKIN that the retry being returned from is a restart of a user channel program (not strictly error recovery CCWs) that had a
track condition check earlier. This means that invalidated seek head
opcodes can be expected. Once a CP I/O or Diagnose I/O channel program has to be restarted
because of a track condition check, the error recovery procedure
invalidates (for Diagnose I/O only) all seek head opcodes in the channel
program and sets the IOERILTR flag (indicating that alternate track
error recovery is in progress) before proceeding. The IOERALTR flag
remains set whenever any portion of the users channel program is being
retried, until the channel program either ends successfully or ends with
a permanent error. The flag does not remain set continuously; there are breaks
while the error recovery procedure takes time out to use its own channel program to read record zero (the channel program is passed back to lOS as a "retry"). At these times the IOERRDRO flag is set instead of the IOERALTR flag. CP Introduction 1-169

During the further execution of a Diagnose Channel prograa,
invalidated seek head opcodes may be encountered once the IOEBILTB flag
is turned on. CP channel programs do not use seek head. The nuaber of
these opcodes encountered may be several, or none at all, depending on
the user's channel program. Also, these invalidated seek heads may be
trying to seek off of an assigned alternate track (usually to the next
logical track) or they aay have no involvement with flagged tracks at
all, again depending on the nature of the user's channel program. Whenever the channel program is stopped by an invalidated seek head, a
determination is made of whether or not it is trying to get off of an
alternate track. This determination is made by looking at the current
cylinder number (available in sense data taken at the time of the command reject) and seeing whether or not it falls within the alternate
track cylinder area at the high end of the disk. If the seek head R2i trying to get off of an alternate track, there is no problea and the
subject channel program is restarted with a seek to the current cylinder
and to the track specified by the invalidated seek head. If the seek
head trying to get off of an alternate track, record zero of the
alternate track is read first to get the cylinder nuaber of the
defective track. Then the subject channel program is restarted with a
seek to the cylinder of the defective track, but to the track specified
by the invalidated seek head. TAPE ERROB RECOVEBY, ERP (D!KTAP) Error recovery is attempted for user-initiated tape I/O operations to
CP-supported devices that use the DIAGNOSE interface. The primary control blocks used for error recovery are the RDEVBLOK, the IOBLOK, and
the IOERBLOK. In addition, auxiliary storage is used for recovery
channel programs (repositioning and erase).
The interruption handler, D!KIOS, performs a SENSE operation when a
unit check occurs. Tape errors are then passed to D!KTIP. The sense
information associated with a unit check is contained in the IOERBLOK. If a channel check is encountered, the channel check interruption
handler determines if retry is possible and passes control to the ERP through the I/O interruption handler. When an error is encountered and ERP receives control, D!KTAP determines if this is the first entry into the ERP for this task. The IOBBCNT (lOB error count) field of the lOB is zero on initial entry. On this first entry, the pointer to the IOEBBLOK is placed in the RDEVIOEB field of the BDEVBLOK. This preserves the original error CSW and sense
information for recording. Thereafter, IOEBBLOKS are discarded before a
retry is attempted or a permanent error is passed to 105. The ERP looks for two other specific conditions. If the error count
field is not zero, entry must be due to a recovery attempt. Thus, it aay be a solicited device end to correct an intervention-required condition
or a retry attempt for either tape repositioning or channel prograa
re-execution.
The EBP keeps track of the number of retries in the IOBRCNT field of
the IOBLOK to determine if a retry limit has been exceeded for a
particular error •. If the specified number of retries fails to correct
the error, the error is recorded and D!KIOS is notified of the peraanent
error by turning on a status flag in the IOBLOK (IOBSTIT=IOBFITIL). If the error is corrected by DMKTIP, the temporary error is not
recorded and control is returned to DMKIOS with error flags all off. When repositioning is required in order to attempt recovery, additional HRP flags are contained in the IOERBLOK to indicate paths for specific
errors (that is, data check on write must reposition, erase, and then
reissue original channel program). 1-170 IB! VM/370 System Logic and Problem Deteraination--Volume 1