CA OPS/MVS OPSREPLY WTOR reply not found rc=12 error

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

After I intercept a message (WTOR) the AOF rules call an OPS/REXX which issued an OPSREPLY to respond to the WTOR reply automatically. Yesterday, I had two return code=12 (WTOR reply not found). I look in the log (OPSLOG & MVS SYSLOG), and the reply came out on the console later after CA-OPS/MVS intercept the message. Most of the times the "REPLY" is available right away.

I have  these questions about trying to fix the skip of reply:

Q1. Why sometimes, replies are not available right away?

Q2. What is the difference between specifying "DELAY" versus "WAIT»?

• Delay = OPSREPLY command processor is delay, what does that means?

• Is all OPSREPLY delay for a unique reply message id?

• My reply message (ex: ONL909E) is issued multiple time for different IBM MQ manager channel or queues, will it stop reply for all of them?

• Wait = CA-OPS/MVS won't reply before x sec have past, will my OPS/REXX wait or do I need to add CMDWAIT on my OPSREPLY command?

Q3. In the entire book "CA-OPS/MVS command and function" there is all lot of "SYSWAIT" parameters, but nowhere it tells what it does or means, no definition?

Environment

z/OS
CA OPS/MVS

Resolution

1)  OPSREPLY Delay(n) is an unconditional wait - no reply will be attempted until the specified seconds have elapsed; Wait(n) is a conditional wait in that OPSREPLY checks each second for a matching WTOR, when found the reply occurs, if after the number of seconds expires and no matching WTOR is found then a bad RC is issued.

• a) just the OPSREPLY with the DELAY- - each OPSREPLY command is unique.

• b) see above response on how OPSREPLY WAIT works, but the REXX exec will not continue to the next instruction until OPSREPLY is done.

2)  SYSWAIT keyword - (Optional) For a cross-system request, the SYSWAIT keyword specifies the number of seconds that CA OPS/MVS should wait for the remote system to receive and respond to the request. The default is the value of the MSFSYSWAIT parameter; you can specify any number of seconds from 1 to 600.

3)  Either way of coding will work - if this is issued from a MSG rule NOOUTPUT is assumed; as a good coding practice you should specify the complete syntax of keywords in place of the accepted abbreviations. And your example did not include msg.replyid, be careful to not create a local variable with the stem name of an OPS/MVS event variable - do not use a local var of replyid as event variable name msg.replyid would be changed.

4)  Use ADDRESS OPER when you are capturing the WTOR, as it is more direct/efficient since the executing code has all the information it needs. Use OPSREPLY after the WTOR/s have been issued if you can not or do not need to when the WTOR is issued. Example - use OPSREPLY when shutting down an application that requires a response/command to a WTOR that is always outstanding, like IDMS or IMS..

Change the message rule to use this statement: ADDRESS OPER "R "msg.replyid",yourintendedreply"