the alternate track cylinder since these may belong to other virtual
machines. A channel program may attempt a transition from one track to
the next by any of the following: • Seek • Seek head • Multi-track search or read • Record overflow
The full seek causes no problem: since it specifies the cylinder as
well as the track, it causes the channel program to leave the alternate
track and to return to a cylinder within the minidisk extent. It is
certain to go back to the minidisk because the seek address was verified
when the virtual CCWs were translated to real.
The multi-track operations and record overflow operations also cause
no problem, because, as explained above, these are caught by the
hardware and result in a track condition check.
The seek head is dealt with as follows. When a seek to an alternate
track is encountered in a virtual channel program by CP during the CCW translation process, CP converts all seek head commands (in the real,
translated CCWs) to an invalid CCW opcode (X'FF'). Then when the
translated channel program is executed, it is interrupted (with a command reject) at each seek head CCW so that the track to which the
channel prograa is seeking can be checked to see that it really belongs
to the virtual machine that requested the I/O. Note that this only
happens to channel programs that seek out of the minidisk to an
alternate track. DMKTRKVA - When DMKCCWTR finds a virtual machine seeking out of its iInidIsk extent to what should be an assigned alternate track, it has to
do a check of the backward record zero pointer to verify that the
alternate belongs to that minidisk. So DMKCCWTR calls DMKTRKV1, passing
the CCBH address of the alternate as input, and DMKTRKVA perforas CP I/O
to read record zero of the alternate and then returns the pointer found
in record zero to DMKCCWTR. - This is called by both DMKUNT and DMKVIO. Its function is to
handle command rejects in channel programs initiated by virtual machine SIO when the channel program was found (by DMKCCWTR) to be seeking to an
alternate track outside the minidisk extent. The command rejects result
because, for these channel programs, any seek head commands have been
invalidated (opcode changed to X'FF') in order to trap seek heads that might switch to another minidisk's track in the alternate track
cylinder.
Note: Even though DMKCCWTR may also find Diagnose I/O channel programs that seek directly to an alternate track and invalidate the seek head
opcodes on these channel prograas, the command rejects resulting froa these channel programs are handled by DMKTRKIN, not by DMKTRKFP. - This routine performs alternate track recovery for CP I/O and
for Diagnose I/O both when the Diagnose channel prograa results in a
track condition check and when a coamand reject results from a seek head
whose opcode DMKCCWTR made invalid. The routine has nothing to do with
alternate track recovery for SIO issued by a virtual machine. But it
does share a few small subroutines with DMKTRKFP.
1-168 IBM VM/310 System Logic and Problem Deter.ination--Volume 1

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