@John, thanks, exactly the *sort* of answer I was looking for.

It was just a Friday question, as I said. No real problem here. I just have 
this "why? whatever for" thought every time I look at the WAIT documentation.

> the parent needs at least 2 worker products in order to do something else

Or perhaps at least one "worker product" plus some necessary "output" resource. 
Although then "any 2 of n" would not solve the problem.

Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Monday, June 20, 2016 7:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WAIT >1 (Friday type question, a day late)

On Sun, Jun 19, 2016 at 11:52 AM, Charles Mills <charl...@mcn.org> wrote:

> Oh sure. The basic "wait for one of many." My code waits for an any 
> one of an operator command, a timer expiration, or "real work."
>
> My question was does anyone issue a wait with a completion count of 
> more than one? "Wake me when two of these five ECBs have been posted"?
>
> Charles
>
>
​That is a good question. I can think of a reason, as you said, to wait for
"1 of n". And I can think of a reason ​to wait for "n of n". I've even thought 
of a reason to wait for what I'll call "1+1 of n" (i.e. what until one specific 
ECB is posted, plus one of "n" other ECBs). The closest that I can envision for 
"2 of n" might be if the "n" are "n" worker threads which produce "some output" 
and, for some reason that I can't envision, the parent needs at least 2 worker 
products in order to do something else. But that idea is so vague that it is 
basically useless. Hum, maybe a case of "efficiency" in the aforementioned 
scenario. Suppose that you need "n"
worker threads to produce "product". These thread each take a relatively 
"large" amount of time. Your main thread does something with this "product", 
but it does it quickly. It would be more efficient to accumulate "m" (<n) units 
of "product" to process in a loop for each redispatch of the main thread. Well, 
a little more reasonable, but still not too specific.

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

Reply via email to