On Sat, 5 May 2012 08:43:59 -0700 Charles Mills <[email protected]> wrote:
:>I have a situation in which it would be a wonderful thing if I could have :>multiple tasks waiting for a single event, without having a separate "wait :>control block" of some sort for each task. Yep. :>Why? I have no control over what the tasks "have" in advance (system exit :>situation) and doing a GETMAIN or the like so that each task could have its :>own ECB, and then chaining them all together, following the chain with :>POSTs, FREEMAINs, etc., etc., would be a real pain, a lot of overhead, and a :>real risk of mucking it up. :>I know WAIT/POST/ECB does not support multiple tasks waiting on a single :>ECB. :>I guess that EVENTS does not support this either -- but I don't see it :>explicitly in the documentation -- is my assumption correct? :>Is there any other way to do this? Some clever use of ENQ or something like :>that? Some other z/OS "wait" service besides WAIT and EVENTS? I have code that involves multiple feeders/multiple eaters. The way I handle it is to have a control task for the eaters which gets woken by the post from the feeders. It then wakes up waiting eater, and starts additional ones if necessary. The gotcha is the serialization, which can be handled quite well by PLO (or by ENQ or SETLOCK by the faint of heart). -- 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
