The perpetually outstanding WTOR is indeed a throwback to very old design. Nonetheless, Netview and its components like System Automation still use this technique decades after it became unnecessary. These WTORs live forever. If one is responded to, even by mistake, Netview throws up a new WTOR.
I can't think of any limits to be wary of when coding a programmatic response. Although these WTORs live forever, there is only one per task at any time. Even if a console is shared across a large parallel sysplex, the total number of messages at any given time is trivial. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Charles Mills Sent: Monday, May 30, 2016 10:49 AM To: [email protected] Subject: (External):Re: Delaying response to a message To answer the question that you actually asked, I think I have seen products that successfully leave a WTOR pending for days. Moving on to the question you did not ask, I know you're dealing with the responses, not the design of the program issuing the WTOR, but I think "perpetual WTORs" are a frowned-upon design choice, with the ability to handle a MODIFY command the preferred approach. Or in this case, it sounds like the program needs to be do a programmatic query of some sort, not look to a (now largely nonexistent) operator. Again, I understand that re-writing the underlying program may not be an option for you. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Zahir Hemini Sent: Monday, May 30, 2016 10:38 AM To: [email protected] Subject: Delaying response to a message Is there a maximum number of outstanding WTORs allowed? How long does a message token last. I have to build a piece of fairly complex logic that has to read data and do look ups before responding to a console message. It can have extreme variability in finding and waiting for a response. Most of the time a response can be looked up and derived quickly, sometime it will have to wait for something else to happen. Here is a simplified example of what I want to do. This is a model of a message that needs a response. Codes in the message inform about specific look up requirements JMX0431R Spin 03 to partner X-M0005 (Y/N) There is an initialization procedure that defines the name of a program to handle this message, because at different times of day different activity is needed. *Initialization procedure AT STARTUP VAR #CMDJMX LEN 8 LET #CMDJMX = 'JMXHND1' /* default handler */ The message is intercepted by this. It defines part of the message text as a variable from which information is to be extracted. MSG=JMX0431R VAR &SPCT POS 14 LEN 4 LOCAL /* parm falls in this range */ VAR &PARM1 LEN 4 LOCAL VAR &PARM2 LEN 14 LOCAL VAR #CMDJMX LEN 8 PARSE NUMERICS &SPCT INTO &PARM1 LET &PARM2 = $$MSGRID /* REPLY ID */ SET DISPLAY=SUPPRESS RUN #CMDJMX ( &PARM1 &PARM2) ASYNCH The numeric value in the message is extracted and the message identifier is obtained. The message is suppressed from the display and an asynchronous program JMXHND1 is started. Control then returns to the message handler. The actual work is done in the asynch program to shorten the path length in the message handler, and to allow a variable name to be used for the handler program. JMXHND1 Command list This command list pics up the parameter extracted from the message and the reply id which were passed. It then does a series of look ups and determines the correct response, which it gives and it then ends. VAR &PARM1 LEN 4 LOCAL VAR &REPID LEN 14 LOCAL PARSE ARGS INTO &PARM1 &REPID IF &PARM1 GT 2 /* READ AND PROCESS */ REPLY &REPID (Y) /* REPLY Y TO LET IT CONTINUE */ This is a simplification of a process I propose to use, but it is possible for a response not to be know for days or even longer. So is there any kind of limits I need to consider before implementing this kind of logic? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
