>It's hard to believe such a disruptive problem can be a stealth problem. >I guess that speaks well of the spin loop recovery routines.
There aren't that many synchdest messages these days anymore that are NOT accompanying a real disabled wait state. So maybe no one at IBM has looked at this in a long time. Our spin loop was detected on Monday morning and had occured on Saturday. In our case the lpar had to get IPLd because RSM recovery may have handled the spin recovery, but something was off in either OMVS, ZFS or Lotus Domino (a lot of users were unable to reach their mail files). That was fixed after IPL. I guess what it boils down to is how IEE178I is issued. IEAVELK issues the message, and as expected the bloody thing is OCO, so I cannot see if it is issued with the request to be held (my guess is not). If it were held, 1. then the operator would need to use the cancel key explicitly acknowledging that he has seen the message. 2. Until he does, console address space would be unable to deliver messages to this console causing further messages to back up until we reach a WTO buffer shortage. And that even if the spin loop has long been resolved. I guess it is a trade-off to not hold the message. Our solution will be to hope for the best (in other words that the spin gets resolved), but on reissuance of the message make it red and send out an email to all and sundry that something had happened, so please go and check if an IPL is required. I shudder to think what happens if we ever run into hot IO (which also issues synchdest messages). Best regards, Barbara -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
