Hi all, Rob Scott's approach = Jackpot:
> (2) The ISV product exit is attempting to notify its associated server via a cross-memory post using an ASCB address stored somewhere in common storage. > (3) It is possible your ISV product has terminated without cleaning up, leaving behind the exit and the common storage control block. Support confirmed that one of their Exits remains active and POSTing ECB signal to the EM (the EM is the independent vendor software that abended issuing the console error) address space, which is not available anymore. It seems to run in, their own words, "the address space of user tasks", so they get a POST System Completion Code. The whole problem has been solved, we just need to install a patch that presumably makes this situation impossible to happen. I guess that a SETPROG filtered by JOBNAME can wipe the exit left behind so there would be no need to IPL. I still don't know, I've got some manuals to read. Regards, Ferran On Wed, Apr 16, 2014 at 9:39 AM, Ferran Perxas <[email protected]>wrote: > Hello Shane, thanks, we thought about that. This shop has a test and > development LPARs with some tape drives already presented. > > Hi Ed, we'll have a look at he EREP. > > > > > On Tue, Apr 15, 2014 at 11:37 PM, Ed Finnell <[email protected]> wrote: > >> Sometimes EREP data can provide enough to distinguish the stomper from >> the stompees. Active PSW REGs and a few lines of failing module can be >> enough >> to see where it started. If it's vendor code they might have seen it >> before or know under what conditions it can be caused. The DB/2 folks were >> particularly adept >> in my opinion. Had one where all but the last few dumps had been purged >> for >> space, but the offender was the first one. Turns out a table had been >> dropped and recreated. When tried to reload it failed. REG 6? Oh, it >> had been >> extended on the fly. Just recreate the table, extend and then do the >> reload. Oh, OK-it worked. >> >> >> In a message dated 4/15/2014 2:59:41 P.M. Central Daylight Time, >> [email protected] writes: >> >> In production outages time is usually a more prized commodity than DASD >> space - educate your operations people. Much has been done to allow disk >> dumps to run pretty quickly - none of that probably helps on tape. >> >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
