The x'30' means that the PRB was waiting on that ECB, but then there was
a Post-without-ECB that unwaited the ECB. RTM would do that in order to ABTERM the TCB (possibly for the CANCEL with DUMP 122 abend). If the TCB is not running now, it should not be because it is waiting on that ECB. Not much more I can tell you without seeing the dump. Is the TCB set nondispatchable? Has parallel detach gotten its fingers in there? Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" <[email protected]> wrote on 06/22/2018 03:14:34 PM: > From: "Steve Smith" <[email protected]> > To: [email protected] > Date: 06/22/2018 05:07 PM > Subject: Eternal WAIT on un-waited ECB > Sent by: "IBM Mainframe Discussion List" <[email protected]> > > I have a bad situation where a program is hanging forever in a wait. The > ECB shows x'30ABFC50'. The lower 3 bytes are the address of my PRB, and I > read somewhere that x'30' means it was un-waited (something like undead, I > guess). This happens after some turmoil, and it's probable, not yet > certain, the ECB looked like that when I waited on it. > > This is actually a VSAM CHECK after an asynchronous POINT. Looking at the > S122 dump, the RPLACTIV flag is on, RPLFDBK is all 0. > > My question is, would clearing the ECB before the asynch. request fix > this? I believe I ought to anyway, but my question is if this could cause > the hang? > > I have no way to re-create the situation. Unfortunately, my customers > evidently do. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
