>From what I can tell from the doc, POSTing an ECB with ECBUNWT already on will >not wake up your waiting client.
If you must use ECBs to serialize between client and server - I suggest an extra timer (and ECB added to your ECBLIST) that would enable your client to sniff your server ECB in ECSA for ECBUNWT and take any appropriate action. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Steve Austin Sent: 22 October 2013 09:23 To: [email protected] Subject: Re: ECB is "unwaited" normally used by ABTERM Thanks for this. However, from what I'm seeing there must be a bit more to it. My client task is waiting on an ECB is ECSA storage obtained by the server address space. It is the server address space that has been forced; the client task is waiting on this ecb and others, but only the one in ECSA owned by the server has ECBUNWT set. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Rob Scott Sent: 22 October 2013 09:03 To: [email protected] Subject: Re: ECB is "unwaited" normally used by ABTERM I found it in "SIS" - here is the abstract : APAR Identifier ...... OY66212 Last Changed ........ 94/09/14 DOC ECB=X'30' UNDEFINED ECBCC = 30 AFTER OPERATOR CANCEL (ABEND122 ABEND222) Symptom ...... DD DOC Status ........... CLOSED PER Severity ................... 3 Date Closed ......... 93/09/04 Component .......... 5752SC1CL Duplicate of ........ Reported Release ......... D22 Fixed Release ............ 999 Component Name 5752 TASK MANAG Special Notice Current Target Date .. Flags SCP ................... Platform ............ Status Detail: CERTIFICATION - APAR solution is being certified by development. ERROR DESCRIPTION: Lack of documentation of the meaning for the X'30' in the high order byte of the user's ECB was causing unnecessary concern when user's are debugging never-ending WAIT problems. When these problems occur, the job is usually cancelled. As part of this asynchronous task termination process the X'30' is stored in the user's ECB, and when the user is debugging the dump, their initial reaction is that the never- ending WAIT was caused by whoever stored the undefined X'30' into the ECBCC. PROBLEM SUMMARY: **************************************************************** * USERS AFFECTED: Systems running MVS/ESA HBB3310 through * * HBB4430. * **************************************************************** * PROBLEM DESCRIPTION: Lack of documentation of the meaning * * for a X'30' in the first byte of the * * user's ECB. * **************************************************************** * RECOMMENDATION: * **************************************************************** If a TCB that is waiting on an ECB/ECB list is ABENDed, those ECBs that have the WAIT bit on may be "unwaited" by the system when ABEND processing is initiated for the TCB. Unwaiting an ECB consists of changing the first byte of the ECB from a X'80' to a X'30'. Bit 0 (the wait bit) is turned off. Bits 2 and 3 are turned on for diagnostic purposes. Users of WAIT / POST should not depend on the system to "unwait" waiting ECBs when a TCB is ABENDed because ECBs are only unwaited under certain circumstances. A typical case where ECB(s) are unwaited is when a job is cancelled by the operator. If the job's TCB is WAITing on an ECB, the ECB will be unwaited when the TCB is forced to begin cancel processing. PROBLEM CONCLUSION: The mapping macro IHAECB has been updated to include an equate for the "unwaited" ECB (ECBUNWT) which documents the meaning of of a X'30' in the first byte of the ECB. This change will also be included in the next release of the MVS/ESA Data Areas Volume 2 as follows. Offsets Dec Hex Type Len Name (Dim) Description 0 (0) CHARACTER 1 ECBCC - COMPLETION CODE BYTE 1... .... ECBWAIT "X'80'"- WAITING FOR COMPLETION OF THE EVENT .1.. .... ECBPOST "X'40'"- THE EVENT HAS COMPLETED ..11 .... ECBUNWT "X'30'"- ECB is "unwaited". (Normally used by ABTERM) Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Steve Austin Sent: 22 October 2013 08:19 To: [email protected] Subject: Re: ECB is "unwaited" normally used by ABTERM Hello Rob, I'm not finding APAR OY66212 on the technical help database. Where can I find it? Thanks -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Rob Scott Sent: 21 October 2013 17:40 To: [email protected] Subject: Re: ECB is "unwaited" normally used by ABTERM Steve The ECBUNWT field was documented in APAR OY66212 Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Steve Austin Sent: 21 October 2013 17:04 To: [email protected] Subject: Re: ECB is "unwaited" normally used by ABTERM Yes and that is what I'm trying t avoid. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Binyamin Dissen Sent: 21 October 2013 16:22 To: [email protected] Subject: Re: ECB is "unwaited" normally used by ABTERM So the client remains waiting? On Mon, 21 Oct 2013 15:31:11 +0100 Steve Austin <[email protected]> wrote: :>The ECB is in ECSA. The RESMGR routine only posts if the ECBWAIT is set :>and it is not, ECBUNWT is set instead. :> :>-----Original Message----- :>From: IBM Mainframe Discussion List [mailto:[email protected]] On :>Behalf Of Binyamin Dissen :>Sent: 21 October 2013 15:26 :>To: [email protected] :>Subject: Re: ECB is "unwaited" normally used by ABTERM :> :>How is your RESMGR checking the ECB? :> :>Is the ECB in common storage? :> :>On Mon, 21 Oct 2013 15:00:58 +0100 Steve Austin :><[email protected]> :>wrote: :> :>:>I have client and a server addess spaces and the client is waiting on :>:>the server. As part of testing I'm "forcing" the server. An addess :>space :>level RESMGR posts the client if the ECBWAIT bit is on. However, :>in this :>case ECBWAIT is not set and ECBUNWT is set. :> :>:>Under what circumstances is ECBUNWT set? :> :>:>Will a post be honoured when ECBUNW is set? -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN This e-mail message has been scanned and cleared by Postini / Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. ---------------------------------------------------------------------- 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 This e-mail message has been scanned and cleared by Postini / Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. ---------------------------------------------------------------------- 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 This e-mail message has been scanned and cleared by Postini / Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. ---------------------------------------------------------------------- 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
