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