On Sunday, 05/01/2011 at 04:46 EDT, "Gillis, Mark" <mark.gil...@ca.com> wrote:
> The problem I have is that product that the CMS-based product appears to > only return information via the program stack. That prompted me to look > for a way to be told about data arriving on the program stack so that I > could read each line as it arrives from the stack and convert it to an > MT CMS event that my dispatcher loop could deal with. > > You've answered my question, the answer being what I suspected (there > not being a way to be notified about data being queued to the stack). > > It's sounding like I should talk to the people who own this CMS-based > product about having it modified to have the option to use something a > little more sophisticated than the program stack to return information. > That's the next step I'll take if this goes any further (which it > probably won't). I figured it was something along those lines. If the program returns information via the stack, then when you run it, you poll that stack upon the program's completion to find if there is any residual data there ( e.g. SENTRIES / queued() ) and then do with it as you will. It wouldn't really make any sense for CMS to supply such an event since you can't differentiate data stacked for transient use by the program itself or for use by a caller. I have seen "wrapper" programs pull such data off the stack and then redistribute that data in some other fashion. I think that would be your easiest path. (Kind of what people do with WAKEUP.) In your case, pull the data, associate it with the called program and some sort of invocation correlator, then Event_Signal your own monitor. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
