Without having any knowledge about either the device or CP... and no
doubt this is obvious to most, but may be confusing for some. The two
highlighted phrases are not related.
The "invalid address" is from the trace itself. It is normal to have
the 07 and 0F with a data length 1, but CP concludes the address of 0
makes no sense and does not display any data for that I/O in your
trace.
The "I/O error" is the device unable or unwilling to do what the
channel program asked for, it is not the result of the fact that the
trace sees no data to dump along with the status.
The evidence is here, where I have no I/O error, but indeed invalid
data address.
TRACE TYPE IO, CPU 0000 TIME 09:52:19.730408
TRACEID = TAP, TRACESET = NULL, IODATA = 32
USER = RVDHEIJ, I/O OLD PSW = 033C0000 801DE7A8
DEVICE = 0180, SCSW = 00C04007 000C8428 0C000001
ESW = 00800000
-> CCW(1) = 07200001 00000000, CCW ADDRESS = 000C8420
********** INVALID DATA ADDRESS **********
I believe it is also normal for tape unit to present an I/O error upon
unload (with intervention required since unloading the tape means
there is no tape mounted anymore). The device would have no other
convenient way to mention that to CP. I do not think a rewind is
rejected because of BOT.
I'm a bit troubled by your sense byte 2 at X'24' that says the ACL is
active in auto or system mode. The ACL in auto mode is a bit of a
hack. Since the next cartridge will be loaded from the ACL, there is
no intervention required and I suppose the unload will just take a
while to complete and then present the unit read and BOT. This means
the unit must not present device end before the next one is loaded.
You've been vague in what hardware is involved. If this is actual 3480
hardware, then I'm suspicious about the autoloader. Because VM does
not really support the autoloader, it is often set in "auto" mode.
That means that the unload will also cause a reload of the next
cartridge from the autoloader (unlike MVS that actually steers the ACT
through a Load Display).
We had major problems in the past, and were already planning to
replace the full bank of 3480s to fix it, like IBM did at another
account (with no success). The real cause turned out to be CA Dynam/T
telling the I/O operators to mount a specific active volume on *any*
unit they liked (unlike MVS that gives specific mount request). So
they were looking around for a unit that was unloading, and put the
active tape there. But when that was in "auto" mode the ACL jammed and
the unit went not-ready. It was most common when a VSE job was coded
with incorrect options. It would take a scratch tape from the ACL,
write to it, unload it, and ask for it again. The tape setup folks
would spot the thing unloading at that moment, and pushed it back in,
jamming the ACL that was busy loading the next scratch cartridge from
the stack. We put in a lot of work to fix JCL not to unload tapes that
were needed again, and kept a few units with ACL-off for mounts of
active tapes (even if that meant tape ops had to take it from one unit
to the next).
Rob
