It is not a tape at all. Neither is it a disk. It is an encryption device that responds to sense commands like it is a tape unit.
A bit of history of the device * Generation 1 was parallel channel connected. It required an RDEVICE statement saying that it was a 3420 model 7. When one was detached from a user, it took nearly 30 minutes to rewind. However, there were no I/O error messages associated with its detachment. * Generation 2 is ESCON connected. It responds to roll-call as if it is a 3480-04. It does not require an RDEVICE. It does return unsolicited sense data when detached from a guest, but there is nothing that appears actionable to the operators in the messages that are generated. * Generation 3 is also ESCON. Initially, it streamed unsolicited interrupts when detached. That has been corrected. Now it gives the command rejects. Since this is a VM-only problem, TPF knows not to rewind it, we could live with the errors at detach time. There would be anywhere from a handful to a few dozen per day. That said, I would rather not condition our operators to become inured to the "normal operation" I/O error messages. They might dismiss real errors as being normal. Why not just code the devices as unsupported devices with DEVCLASS TAPE? It seems that we are taking a step backwards if we do that. The Generation 2 devices required no special treatment of that ilk. I prefer to keep the RDEVICE section of the SYSTEM CONFIG to a bare minimum. This is not rooted in any fear of having unsupported devices on the system. Rather, it is because hardware gets moved around by a separate hardware group, sometimes without prior notice. Moving a set of devices that has been accorded special treatment in the System Config could break two sets of devices. And it would definitely not be done at a time that was convenient for me. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij > Sent: Wednesday, July 23, 2008 2:08 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Interpreting Trace > > 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 >
