Re: WAIT ECB WITH 00 First Byte

2011-12-20 Thread Shmuel Metz (Seymour J.)
In
,
on 12/18/2011
   at 01:24 AM, Jim Mulder  said:

>I could not find anything in the manuals which says this, but it has
>worked this way for at least 30 years.

It's worked that way since the 1960's, although my documentation[1] is
somewhat more recent.

[1] GY28-6659-7,
IBM System/360 Operating System
MVT Supervisor
dated May 1973. 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-19 Thread Peter Relson
For "normal completion", the resetting of the other ECB's wait bits is 
done, as Jim Mulder points out.
For "abnormal completion" (i.e., if you were waiting and woke up in your 
recovery whether due to cancel or some other asynchronous abend), don't 
count on it 

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-18 Thread Robert A. Rosenberg
At 01:24 -0500 on 12/18/2011, Jim Mulder wrote about Re: WAIT ECB 
WITH 00 First Byte:



  Quoting from the MVS/XA SP2.1.0 version of IEAVEPST (5 years
before it became OCO in MVS/ESA SP3.1.0, so some of you
probably have this on microfiche that you have squirreled away
somewhere):

* WHEN THE WAIT COUNT BECOMES ZERO, THIS CHECKS IF THERE WAS A LIST
* OF ECB'S BEING WAITED ON BIGGER THAN THE WAIT COUNT. IF SO, THE
* LIST ADDRESS IS FOUND (GETTING REG 1 FROM WHERE THE RB'S REGISTERS
* WERE SAVED). ALL OF THE ECB'S WAIT FLAGS (EXCEPT FOR THE ECB BEING
* POSTED) ARE RESET TO ZERO.
 SPACE 1
*/* D (NO,TCBREADY,YES,) RB SEARCH BIT IS ON*/
 TMRBSTAB2,RBECBWTECB'S SEARCH FLAG SET
 BZTCBREADY   NO, BRANCH
*/*LOOP3: P FIND TCB- GET SAVED ECBLIST ADDRESS*/
 L R10ECBP,TCBGRS1ASSUME REGS IN TCB
 CLR5RB,TCBRBPECB'S RB TOP OF QUEUE
 BERESETWTYES, BRANCH
 L R3WORK,TCBRBP  GET ADDRESS OF TOP RB
* NOTE -- HIGH BYTE OF R3 MUST REMAIN ZERO THROUGH LOOP
LOOP3L R10ECBP,RBGRS1-RBSECT(,R3WORK) LOAD RB REG 1
 ICM   R3WORK,M0111,RBLINKB-RBSECT(R3WORK) GET NEXT RB ADDR
*  (HIGH BYTE ALREADY CLEARED)
 CLR   R3WORK,R5RBFOUND WAITING RB
 BNE   LOOP3  NO, BRANCH 


  I could not find anything in the manuals which says this, but
it has worked this way for at least 30 years.


Does this apply not only to a WAIT call using ECBLIST but also to the 
EVENTS call? It has been a while since I coded but I have the 
impression that once issued the interface would handle each ECB as a 
separate event and that there was no need to issue the call more than 
once (and that in fact if not all the ECBs were handled, it was 
needed to issue a EVENTS call to cancel the wait on any 
non-yet-posted ECBs.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-18 Thread Binyamin Dissen
On Sun, 18 Dec 2011 01:24:40 -0500 Jim Mulder  wrote:

:>> :>My understanding, which might be incorrect or incomplete, is that WAIT 
:>sets 
:>> :>the wait bits, stores the RB address in the ECBs, sets the wait 
:>> count in the 
:>> :>RB and puts the task in a wait state.  At that point, isn't WAIT 
:>finished?
 
:>> :>POST sets the post bit, clears the wait bit, decrements the wait 
:>> count if it 
:>> :>is greater than zero, then if it is zero, makes the task dispatchable. 

:>> :>The ECBs are not reset.
 
:>> That was my point. If the ECBLIST has 5 ECBs and the wait count is 1, 
:>posting
:>> one of the ECBs causes the task to be dispatched without resetting the 
:>wait
:>> bit in the other ECBs.

:>  Quoting from the MVS/XA SP2.1.0 version of IEAVEPST (5 years
:>before it became OCO in MVS/ESA SP3.1.0, so some of you 
:>probably have this on microfiche that you have squirreled away 
:>somewhere):

:>* WHEN THE WAIT COUNT BECOMES ZERO, THIS CHECKS IF THERE WAS A LIST 
:>* OF ECB'S BEING WAITED ON BIGGER THAN THE WAIT COUNT. IF SO, THE 
:>* LIST ADDRESS IS FOUND (GETTING REG 1 FROM WHERE THE RB'S REGISTERS
:>* WERE SAVED). ALL OF THE ECB'S WAIT FLAGS (EXCEPT FOR THE ECB BEING
:>* POSTED) ARE RESET TO ZERO. 
:> SPACE 1 
:>*/* D (NO,TCBREADY,YES,) RB SEARCH BIT IS ON*/ 
:> TMRBSTAB2,RBECBWTECB'S SEARCH FLAG SET 
:> BZTCBREADY   NO, BRANCH 
:>*/*LOOP3: P FIND TCB- GET SAVED ECBLIST ADDRESS*/ 
:> L R10ECBP,TCBGRS1ASSUME REGS IN TCB 
:> CLR5RB,TCBRBPECB'S RB TOP OF QUEUE 
:> BERESETWTYES, BRANCH 
:> L R3WORK,TCBRBP  GET ADDRESS OF TOP RB 
:>* NOTE -- HIGH BYTE OF R3 MUST REMAIN ZERO THROUGH LOOP 
:>LOOP3L R10ECBP,RBGRS1-RBSECT(,R3WORK) LOAD RB REG 1 
:> ICM   R3WORK,M0111,RBLINKB-RBSECT(R3WORK) GET NEXT RB ADDR 
:>*  (HIGH BYTE ALREADY CLEARED) 
:> CLR   R3WORK,R5RBFOUND WAITING RB 
:> BNE   LOOP3  NO, BRANCH  

:>  I could not find anything in the manuals which says this, but
:>it has worked this way for at least 30 years.

Very interesting. So I have useless logic after ECBLIST waits, resetting the
non-posted ECBs to zero. The status will either be posted or zero.

--
Binyamin Dissen 
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 lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-18 Thread Shmuel Metz (Seymour J.)
In , on 12/17/2011
   at 10:30 PM, Binyamin Dissen  said:

>That was my point. If the ECBLIST has 5 ECBs and the wait count is 1,
>posting one of the ECBs causes the task to be dispatched without
>resetting the wait bit in the other ECBs.

Your point is in error. POST resets all of the ECB's in the list that
previously had bit 0 set.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-17 Thread Jim Mulder
> :>My understanding, which might be incorrect or incomplete, is that WAIT 
sets 
> :>the wait bits, stores the RB address in the ECBs, sets the wait 
> count in the 
> :>RB and puts the task in a wait state.  At that point, isn't WAIT 
finished?
> 
> :>POST sets the post bit, clears the wait bit, decrements the wait 
> count if it 
> :>is greater than zero, then if it is zero, makes the task dispatchable. 

> :>The ECBs are not reset.
> 
> That was my point. If the ECBLIST has 5 ECBs and the wait count is 1, 
posting
> one of the ECBs causes the task to be dispatched without resetting the 
wait
> bit in the other ECBs.

  Quoting from the MVS/XA SP2.1.0 version of IEAVEPST (5 years
before it became OCO in MVS/ESA SP3.1.0, so some of you 
probably have this on microfiche that you have squirreled away 
somewhere):

* WHEN THE WAIT COUNT BECOMES ZERO, THIS CHECKS IF THERE WAS A LIST 
* OF ECB'S BEING WAITED ON BIGGER THAN THE WAIT COUNT. IF SO, THE 
* LIST ADDRESS IS FOUND (GETTING REG 1 FROM WHERE THE RB'S REGISTERS
* WERE SAVED). ALL OF THE ECB'S WAIT FLAGS (EXCEPT FOR THE ECB BEING
* POSTED) ARE RESET TO ZERO. 
 SPACE 1 
*/* D (NO,TCBREADY,YES,) RB SEARCH BIT IS ON*/ 
 TMRBSTAB2,RBECBWTECB'S SEARCH FLAG SET 
 BZTCBREADY   NO, BRANCH 
*/*LOOP3: P FIND TCB- GET SAVED ECBLIST ADDRESS*/ 
 L R10ECBP,TCBGRS1ASSUME REGS IN TCB 
 CLR5RB,TCBRBPECB'S RB TOP OF QUEUE 
 BERESETWTYES, BRANCH 
 L R3WORK,TCBRBP  GET ADDRESS OF TOP RB 
* NOTE -- HIGH BYTE OF R3 MUST REMAIN ZERO THROUGH LOOP 
LOOP3L R10ECBP,RBGRS1-RBSECT(,R3WORK) LOAD RB REG 1 
 ICM   R3WORK,M0111,RBLINKB-RBSECT(R3WORK) GET NEXT RB ADDR 
*  (HIGH BYTE ALREADY CLEARED) 
 CLR   R3WORK,R5RBFOUND WAITING RB 
 BNE   LOOP3  NO, BRANCH  


  I could not find anything in the manuals which says this, but
it has worked this way for at least 30 years.

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-17 Thread Binyamin Dissen
On Fri, 16 Dec 2011 07:34:35 -0600 Tom Marchant 
wrote:

:>On Fri, 16 Dec 2011 00:30:52 +0200, Binyamin Dissen wrote:

:>>AFAIK multi-ecb WAIT (for example, 5 ECBs, count of 1) does not reset the
:>>additional ECB's when the count is reached.

:>Not sure what you mean by this, Binyamin.  

:>My understanding, which might be incorrect or incomplete, is that WAIT sets 
:>the wait bits, stores the RB address in the ECBs, sets the wait count in the 
:>RB and puts the task in a wait state.  At that point, isn't WAIT finished?

:>POST sets the post bit, clears the wait bit, decrements the wait count if it 
:>is greater than zero, then if it is zero, makes the task dispatchable. 
:>The ECBs are not reset.

That was my point. If the ECBLIST has 5 ECBs and the wait count is 1, posting
one of the ECBs causes the task to be dispatched without resetting the wait
bit in the other ECBs.

--
Binyamin Dissen 
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 lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-17 Thread Binyamin Dissen
On Fri, 16 Dec 2011 07:14:21 -0600 Donald Likens 
wrote:

:>I see this situation in a locked up (waiting forever) environment. I have no 
idea how it gets set this way. I have decided to do it another way.

It means that something cleared it incorrectly. An ECB that is being waited
upon should not be cleared.

--
Binyamin Dissen 
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 lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-16 Thread Shmuel Metz (Seymour J.)
In
<77142d37c0c3c34da0d7b1da7d7ca3459...@nwt-s-mbx2.rocketsoftware.com>,
on 12/16/2011
   at 06:09 PM, Bill Fairchild  said:

>The completion code (not post code) is placed in at least bits 2-31
>of the full word. 

I never noticed that piece of nomenclature before, but apparently it
goes back to the very early days; I found it in the old Control
Program Services manual. Thanks.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-16 Thread Bill Fairchild
The completion code (not post code) is placed in at least bits 2-31 of the full 
word.  So it is true that the code is in the lower 3 bytes, and it is also true 
that the code is in the lower 4 bytes (FSVO "4").

Comments from within the IHAECB mapping macro:
*/*02*  An ECB can be posted with a two-part completion code:
*/*02*   -  Bits 1 through 7 are posted by data management   
*/* and teleprocessing functions.  This part of the  
*/* completion code is described in the mapping of the   
*/* ECB control block.   
*/*02*   -  Bits 8 through 31 are posted by all system components
*/* and by user-written programs.  When a task is abnormally 
*/* terminated, the ECB for the task is posted with an   
*/* abnormal system completion code in bits 8 through 19,
*/* or with an abnormal user completion code in  
*/* bits 20 through 31.  

>From the Authorized Assembler Services book:
Bits 2 through 31 are set to the specified completion code.

Bill Fairchild

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Friday, December 16, 2011 10:02 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: WAIT ECB WITH 00 First Byte

In ,
on 12/16/2011
   at 07:51 AM, "McKown, John"  said:

>The "post code" is placed in the lower 3 bytes by POST, where the RB 
>address is placed by the WAIT.

Lower 4 bytes ;-)

>I will bet that the contents are undisturbed. If so, this means that 
>those ECBs will have Bit 0 set to '1'b, Bit 1 set to '0'b, and the RB 
>address in the lower 3 bytes

How much did you want to bet?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-16 Thread McKown, John
> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Friday, December 16, 2011 10:02 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: WAIT ECB WITH 00 First Byte
> 
> In ,
> on 12/16/2011
>at 07:51 AM, "McKown, John"  said:
> 
> >The "post code" is placed in the lower 3 bytes by POST, where the RB
> >address is placed by the WAIT.
> 
> Lower 4 bytes ;-)
> 
> >I will bet that the contents are undisturbed. If so, this means that
> >those ECBs will have Bit 0 set to '1'b, Bit 1 set to '0'b, and the
> >RB address in the lower 3 bytes
> 
> How much did you want to bet?

I'll bet "a hardy well done!" 

>  
> -- 
>  Shmuel (Seymour J.) Metz, SysProg and JOAT

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-16 Thread Shmuel Metz (Seymour J.)
In ,
on 12/16/2011
   at 07:51 AM, "McKown, John"  said:

>The "post code" is placed in the lower 3 bytes by POST, where the RB
>address is placed by the WAIT.

Lower 4 bytes ;-)

>I will bet that the contents are undisturbed. If so, this means that
>those ECBs will have Bit 0 set to '1'b, Bit 1 set to '0'b, and the
>RB address in the lower 3 bytes

How much did you want to bet?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-16 Thread Tom Marchant
On Fri, 16 Dec 2011 07:14:21 -0600, Donald Likens wrote:

>I see this situation in a locked up (waiting forever) environment. 
>I have no idea how it gets set this way. I have decided to do it 
>another way.

Previously, On Wed, 14 Dec 2011 22:59:37 -0600, Donald Likens wrote:

>I know that an ECB's first byte is x'80' if waiting and x'40' if posted 
>but what does X'00' mean. When I zero out the ECB I zero out the 
>whole word. This ECB has a PRB in it.

If you were waiting and you saw in a dump that the first byte of the 
ECB was zero, that means that someone zeroed the byte when they 
shouldn't have.

If you have an ECB with the wait and post bits off and an RB address 
in it, the wait bit must have been zeroed after the WAIT was issued 
and POST must not have been issued.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-16 Thread Tom Marchant
On Fri, 16 Dec 2011 07:34:35 -0600, Tom Marchant  
wrote:

>On Fri, 16 Dec 2011 00:30:52 +0200, Binyamin Dissen wrote:
>
>>AFAIK multi-ecb WAIT (for example, 5 ECBs, count of 1) does not reset the
>>additional ECB's when the count is reached.
>
>Not sure what you mean by this, Binyamin.
>
>My understanding, which might be incorrect or incomplete, is that WAIT sets
>the wait bits, stores the RB address in the ECBs, sets the wait count in the
>RB and puts the task in a wait state.  At that point, isn't WAIT finished?
>
>POST sets the post bit, clears the wait bit, decrements the wait count if it
>is greater than zero, then if it is zero, makes the task dispatchable.
>The ECBs are not reset.

I should have said, POST sets the post bit, if the wait bit is set, clears the 
wait bit, decrements the wait count in the RB if the wait count is greater 
than zero, then if it is zero, it makes the task dispatchable.

Similarly, if the post bit in an ECB is set, WAIT does not set the wait bit. 
Also, the wait count is set to the count specified minus the number of ECBs 
that were found to have the post bit already set, but not less than zero. 
If the wait count is not zero, the task is put into a wait state.

Just my understanding.

--
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-16 Thread McKown, John
> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Tom Marchant
> Sent: Friday, December 16, 2011 7:35 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: WAIT ECB WITH 00 First Byte
> 
> On Fri, 16 Dec 2011 00:30:52 +0200, Binyamin Dissen wrote:
> 
> >AFAIK multi-ecb WAIT (for example, 5 ECBs, count of 1) does 
> not reset the
> >additional ECB's when the count is reached.
> 
> Not sure what you mean by this, Binyamin.  
> 
> My understanding, which might be incorrect or incomplete, is 
> that WAIT sets 
> the wait bits, stores the RB address in the ECBs, sets the 
> wait count in the 
> RB and puts the task in a wait state.  At that point, isn't 
> WAIT finished?
> 
> POST sets the post bit, clears the wait bit, decrements the 
> wait count if it 
> is greater than zero, then if it is zero, makes the task 
> dispatchable. 
> The ECBs are not reset.
> 
> -- 
> Tom Marchant

The "post code" is placed in the lower 3 bytes by POST, where the RB address is 
placed by the WAIT.
ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A3A0/28.1

Use the POST macro to set a specified event control block (ECB) to indicate the 
occurrence of an event. If this event satisfies the requirements of an 
outstanding WAIT or EVENTS macro, the waiting task is taken out of the wait 
state and dispatched according to its priority.

The bits in the ECB are set as follows:

Bit 0 of the specified ECB is set to 0 (wait bit).
Bit 1 is set to 1 (complete bit).
Bits 2 through 31 are set to the specified completion code. 


Now, when you are waiting on multiple ECBs and the wait number is less than the 
number of ECBs WAIT'ed upon, what happens to the contents of the non-POSTed 
ECBs? I will bet that the contents are undisturbed. If so, this means that 
those ECBs will have Bit 0 set to '1'b, Bit 1 set to '0'b, and the RB address 
in the lower 3 bytes. But I'm not sure of that. I don't have the code to the 
WAIT logic. And I'm too lazy to run a test.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-16 Thread Tom Marchant
On Fri, 16 Dec 2011 00:30:52 +0200, Binyamin Dissen wrote:

>AFAIK multi-ecb WAIT (for example, 5 ECBs, count of 1) does not reset the
>additional ECB's when the count is reached.

Not sure what you mean by this, Binyamin.  

My understanding, which might be incorrect or incomplete, is that WAIT sets 
the wait bits, stores the RB address in the ECBs, sets the wait count in the 
RB and puts the task in a wait state.  At that point, isn't WAIT finished?

POST sets the post bit, clears the wait bit, decrements the wait count if it 
is greater than zero, then if it is zero, makes the task dispatchable. 
The ECBs are not reset.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-16 Thread Donald Likens
I see this situation in a locked up (waiting forever) environment. I have no 
idea how it gets set this way. I have decided to do it another way.

Thanks for your help.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


Re: WAIT ECB WITH 00 First Byte

2011-12-15 Thread Bill Fairchild
ECBs do not have RBs in them.  An ECB contains the 3-byte address of an RB in 
the low-order 3 bytes.

Bill Fairchild

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Thursday, December 15, 2011 1:24 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: WAIT ECB WITH 00 First Byte

In , on 12/15/2011
   at 10:57 AM, Binyamin Dissen  said:

>WAIT will be OK if the ECB x'80' has the correct RB in it,

I can't think of a legitimate way for that to occur. Have you verified that it 
doesn't ABEND?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: WAIT ECB WITH 00 First Byte

2011-12-15 Thread Binyamin Dissen
On Thu, 15 Dec 2011 14:23:46 -0500 "Shmuel Metz (Seymour J.)"
 wrote:

:>In , on 12/15/2011
:>   at 10:57 AM, Binyamin Dissen  said:

:>>WAIT will be OK if the ECB x'80' has the correct RB in it, 

:>I can't think of a legitimate way for that to occur. Have you verified
:>that it doesn't ABEND?

AFAIK multi-ecb WAIT (for example, 5 ECBs, count of 1) does not reset the
additional ECB's when the count is reached. But I could be wrong.

--
Binyamin Dissen 
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: WAIT ECB WITH 00 First Byte

2011-12-15 Thread Shmuel Metz (Seymour J.)
In , on 12/15/2011
   at 10:57 AM, Binyamin Dissen  said:

>WAIT will be OK if the ECB x'80' has the correct RB in it, 

I can't think of a legitimate way for that to occur. Have you verified
that it doesn't ABEND?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: WAIT ECB WITH 00 First Byte

2011-12-15 Thread Charles Mills
Zero means not posted but nobody waiting. The store is locked, and there are
no customers waiting outside the door.

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Donald Likens
Sent: Thursday, December 15, 2011 12:00 AM
To: IBM-MAIN@bama.ua.edu
Subject: WAIT ECB WITH 00 First Byte

I know that an ECB's first byte is x'80' if waiting and x'40' if posted but
what does X'00' mean. When I zero out the ECB I zero out the whole word.
This ECB has a PRB in it.

Thank You for your help.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: WAIT ECB WITH 00 First Byte

2011-12-15 Thread Binyamin Dissen
On Wed, 14 Dec 2011 22:59:37 -0600 Donald Likens 
wrote:

:>I know that an ECB's first byte is x'80' if waiting and x'40' if posted but 
what does X'00' mean. When I zero out the ECB I zero out the whole word. This 
ECB has a PRB in it.

More precisely:

WAIT will not wait on an ECB with X'40' set.

WAIT will store the rb address if the ECB is zero.

WAIT will be OK if the ECB x'80' has the correct RB in it, and ABEND if not.
Two UOW cannot wait on the same ECB.

There is no problem zeroing an ECB that is not being waited upon, as long as
you consider that it may be POSTed.

--
Binyamin Dissen 
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


WAIT ECB WITH 00 First Byte

2011-12-14 Thread Donald Likens
I know that an ECB's first byte is x'80' if waiting and x'40' if posted but 
what does X'00' mean. When I zero out the ECB I zero out the whole word. This 
ECB has a PRB in it.

Thank You for your help.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html