> :>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*/
TM RBSTAB2,RBECBWT ECB'S SEARCH FLAG SET
BZ TCBREADY NO, BRANCH
*/*LOOP3: P FIND TCB- GET SAVED ECBLIST ADDRESS*/
L R10ECBP,TCBGRS1 ASSUME REGS IN TCB
CL R5RB,TCBRBP ECB'S RB TOP OF QUEUE
BE RESETWT YES, BRANCH
L R3WORK,TCBRBP GET ADDRESS OF TOP RB
* NOTE -- HIGH BYTE OF R3 MUST REMAIN ZERO THROUGH LOOP
LOOP3 L R10ECBP,RBGRS1-RBSECT(,R3WORK) LOAD RB REG 1
ICM R3WORK,M0111,RBLINKB-RBSECT(R3WORK) GET NEXT RB ADDR
* (HIGH BYTE ALREADY CLEARED)
CLR R3WORK,R5RB FOUND 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
