Say... could it be that the virtualized silver tape reflector fell off the beginning or end of the virtualized tape? And are you sure that the virtualized silver tape reflector is on opposite edges of the shiny surface of the virtualized tape media? I can't remember which edge gets the leading and trailing silver tape reflectors. You'll have to ask your hardware supplier to experiment with opposite edges. ;-)
Greybeards... indeed! Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Schuh, Richard" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 07/23/2008 10:22 AM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Interpreting Trace Thank, Alan. Your analysis confirms my faded memories of the channel and device protocols. I will pass the information on. Actually, there is no BOT and there is no tape. The vendor chose to reply like a tape drive to the roll-call for reasons unknown to me. I speculate that it is because tape units can be written to and read from in a successive operations. If that is the case, they could have chosen an old printer that allows one to read the print buffer. And they respond unconditionally to sense commands as though the device were at BOT. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Tuesday, July 22, 2008 6:11 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Interpreting Trace > > On Tuesday, 07/22/2008 at 01:57 EDT, "Schuh, Richard" > <[EMAIL PROTECTED]> > wrote: > > TRACE TYPE IO, CPU 0005 TIME 16:28:05.323115 > > TRACEID = T670, TRACESET = NULL, IODATA = 128 > > USER = SYSTEM, I/O OLD PSW = 0704D001 80000000 > 00000000 002C0FBE > > DEVICE = 0670, SCSW = 01C04017 00AA4088 0E000001 ** > I/O ERROR > > ** > > > ESW = 00800000 > > I/O PRIORITIES: CHANNEL = 0, CURRENT = 255, ORIGINAL = 255 > > OUT-PRIORITIZED COUNT = 0 > > -> CCW(1) = 07600001 00000000, CCW ADDRESS = 00AA4080 > > ********** INVALID DATA ADDRESS ********** > > -> CCW(2) = 0F200001 00000000, CCW ADDRESS = 00AA4088 > > ********** INVALID DATA ADDRESS ********** > > > The vendor says that the device has been modified to return > Device End > for both > > the Rewind (CCW Op Code 07) and the Rewind and Unload (0F) > commands. > > In > the > > penultimate entry, you can see that there is a Rewind chained to a > Rewind and > > Unload. Both of those CCWs are flagged in the trace as > having invalid > data > > addresses. This is puzzling because the I/O was generated by CP. If > there are, > > indeed, invalid data addresses, sould that not cause a > Channel Program > Check or > > some other error rather than Command Reject? Why is CP using invalid > channel > > programs in the first place? > > Those are control operations. The address and length fields > are not [supposed to be] used by the device. The channel > does not generate UNIT CHECKs and does not manufacture SENSE > data. The 'invalid data address' is the result of a > determination by CP, not the channel subsystem, at the time > the record was cut. I've seen this when CP puts bad > addresses in CCWs specifically to catch unexpected data > transfer attempts. > > > Here is the pertinent section from the OPERATOR console: > > > > 15:47:21 TAPE 0670 DETACHED RSCHUH 0670 BY > RSCHUH > > 15:47:21 HCPERP500I TAPE 0670 AN OPERATION WAS TERMINATED BECAUSE > A > > 15:47:21 HCPERP500I COMMAND REJECT ERROR > OCCURRED > > 15:47:21 HCPERP6300I SENSE DATA FORMAT = 02 MSG CODE = > 00 > > 15:47:21 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = > 07 > > 15:47:21 HCPERP6303I SENSE = 80482427 00000020 00000000 00000000 > 00000000 > > 15:47:21 HCPERP6303I 00000000 0F010000 > 00000000 > > 15:47:21 HCPERP6304I IRB = 01C04017 00AA4088 0E000001 > 00800000 > > 15:47:21 HCPERP6305I USERID = > SYSTEM > > 15:47:21 HCPERP2216I CHANNEL PATH ID = > 52 > > 15:47:21 HCPERP2220I PHYSICAL CHANNEL PATH ID = > 0168 > > > > According to the vendor, their internal trace shows that > their machine > received > > the Rewind and responded with Device End. The next thing > they saw was > the Sense. > > The first 4 bytes of SENSE data (80482427) show that > - X'80': The device is rejecting the REWIND > - X'48': Drive is online and is at beginning-of-tape. > - X'24': Path 2 to the device is raising the error > : The autoloader has cartridges in it > - X'27': Error recovery action = (what you see in the HCPERP messages) > > Byte 7 says it is format X'20' sense data, so starting at byte 24: > - X'0F': ESCON 4.5 MB/s channel > - X'01': Autoloader is installed > > With no knowledge of the device, I'd say they rejected the > REWIND because > it was already at BOT, but regardless, the evidence points to > the device, > not to the channel or CP. > > Alan Altmark > z/VM Development > IBM Endicott > The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
