I don't want our hardware folks to have to go into the bay and turn the
device around or use a twisted pair to connect it. :-)
Alan, When you said the error is being raised by path 2 to the device,
were you referring to a chpid? The response to a query paths command
shows only one path.
Regards,
Richard Schuh
________________________________
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter
Sent: Wednesday, July 23, 2008 8:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Interpreting Trace
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.
