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
