Unfortunately, we cannot predict when the message will occur or which of the 1920 devices, all DASDD with 8 channel paths to each LCU. The OPERATOR id is only the recipient of the message. Trapping the message is too late in the process. I may have to call on TRSOURCE/TRSAVE with some sort of action routine to stop the trace to keep the trace from deleting the needed TRF. My only problem with that is that it will cause performance problems for our users, as all of the TPF test system database disks are included in that count, and the I/O rates to the string are sometimes almost unbelievable they are so high. That would imply huge trace files and lots of them in order to trap the culprits.
We are taking a different approach for the present, with the TRFs as a backup. We have reported the problem to our hardware vendors, both M/F and DASD, to see what they can find. Too bad that this wasn't on our SHARK DASD. Then there would be only 1 vendor involved; it wouldn't matter where the problem was. Regards, Richard Schuh > -----Original Message----- > From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] > Behalf Of Mike Walter > Sent: Sunday, November 13, 2005 11:02 AM > To: [email protected] > Subject: Re: Message HCPDPM1281I > > > I can't hazard a guess as to *why* the mismatch occurs, but > maybe you can > catch it in the act before things get restored to normal by > trapping the > HCP message with PROP or VM:Operator, and coding up an action > routine to > automatically issue diagnostic commands? It might be worth setting a > global variable that only allows the action routine it issue > diagnostic > commands only once per device or path so that the console log > won't get > swamped. > > Mike Walter > Hewitt Associates > The opinions expressed herein are mine alone, not my employer's. > > > > "Schuh, Richard" <[EMAIL PROTECTED]> > > Sent by: "VM/ESA and z/VM Discussions" <[email protected]> > 11/11/2005 03:20 PM > Please respond to > "VM/ESA and z/VM Discussions" <[email protected]> > > > > To > [email protected] > cc > > Subject > Message HCPDPM1281I > > > > > > > We periodically get the message > > 18:07:57 HCPDPM1281I Path 2D to device 780D now offline; path > group ID > mismatch. > > for devices on a dasd string. These devices are used by a native TPF > system and by TPF guests of VM. The description I find is: > > HCP1281I Path channel to device rdev now offline; path group > ID mismatch. > > > Explanation: The operating system has detected that one of > the paths to a > > device has a path group ID that does not match that which the > system uses > to > access the device. Since attempts to use this path would > result in "hang" > > conditions, the system has marked the path offline. > > System Action: System action continues. > > Operator Response: If possible, physically reset the path > and then vary > it > online to that device. > > The system seems to chug along normally. If we query paths to > one of the > devices, it shows all paths to be both physically and > logically available. > Can anyone hazard a guess as to (a) What the message is > trying to tell us, > and (b) what should be done about it? FWIW, the DASD is HDS. > > > Regards, > Richard Schuh > > > > > > 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. >
