If you can determine which products or functions in your environment can
dynamically alter UCB info, you could start there and place slips traps on
them.
The first step I would take is to set up an automatic display command (D
U,,,xxx,yy) to display all UCBs that have been affected starting at
All, we have a problem that just reared its ugly head the other night.
It happened again last night. (different volume than the previous night)
We do a display unit on one of our LPAR's and get the following:
First LPAR
D,U,,,3169,2
IEE457I 14.39.08 UNIT STATUS 291
UNIT TYPE STATUS
In a message dated 6/9/2005 8:29:53 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
How could the volser get messed up on one LPAR like that? TTOP04 is the
correct volser but the first LPAR doesn't indicate that. Anyone seen
this before?
Somethings overlaying it! Guess I'd start
Of Ed Finnell
Sent: Thursday, June 09, 2005 10:35 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Volume Problem - z/OS 1.4
In a message dated 6/9/2005 8:29:53 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
How could the volser get messed up on one LPAR like that? TTOP04 is the
correct volser
Bill, looks like the first 4 bytes of UCBVOLI (volume serial in UCB)
have been overlaid.
IBM info APAR II13210 describes various UCB overlay problems in IBM and
ISV code.
APAR OA01712 describes a UCBVOLI overlay.
If you can vary the device offline and back online on the problem LPAR
it
:11 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Volume Problem - z/OS 1.4
This may seem like an obvious solution, but have you tried to vary the
unit offline and online again on the LPAR in error?
Richard Habres
AVP; Enterprise Storage Technology
Merrill Lynch
on 6/9/05 9:35 AM, Ed Finnell at [EMAIL PROTECTED] wrote:
In a message dated 6/9/2005 8:29:53 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
How could the volser get messed up on one LPAR like that? TTOP04 is the
correct volser but the first LPAR doesn't indicate that. Anyone
7 matches
Mail list logo
