Host Environment Commands › ADDRESS OPER Host Environment › Issue a Command and Process the Command Response

Issue a Command and Process the Command Response

Utilize the ADDRESS OPER host environment to issue a command and programmatically process the command responses

To issue a command and programmatically process the command output

1. Ensure that an OPS/REXX function does not exist for the command response output that you want to process.

   OPS/REXX functions are an integral component of CA OPS/MVS that retrieve a wide variety of system data needed to make programmatic decisions within AOF rules and OPS/REXX programs. These functions are much more efficient than the equivalent system command, and in some cases retrieve data that cannot be retrieved with any system command. Additionally, these functions allow you to obtain the information synchronously from within AOF rules.

2. Since no waiting is allowed from within AOF rules, except in Request (REQ) rules, the NOOUTPUT option is always enforced and no command response output is collected for programmatic processing. To circumvent this and successfully collect and process command responses, you can dispatch or trigger an OPS/REXX program from an AOF rule to a CA OPS/MVS OSF TSO class server as shown in this example:

   )MSG IST521I
   )PROC
   /* React to GBIND failures if the from node is A45PROD.   */
   /* The logic of this rule simply interrogates the message */
   /* text to see if this is a GBIND failure for the A45PROD */
   /* node. If it is, then we need to trigger an EXEC called */
   /* IST521I to run in an OSF TSO server. This is needed    */
   /* because we need to issue VTAM commands and interrogate */
   /* the command output, and waiting can't be done from     */
   /* within the AOF rule environment.                       */
   /*                                                        */
   /* IST521I GBIND failed for ISTCOS from A45PROD to A04X99 */
   fromnode = WORD(MSG.TEXT,7)
   tonode = WORD(MSG.TEXT,9)
   if fromnode ¬= 'A45PROD' then return       /* NOT A45PROD */
   /* Trigger OPS/REXX program IST521I to an OPSOSF server   */
   /* passing it the nodes as arguments. IST521I would be    */
   /* located in the OPSEXEC or SYSEXEC concatenation of the */
   /* OPSOSF procedure. This program would then contain the  */
   /* Address OPER host environment command to issue the     */
   /* needed VTAM display command and successfully           */
   /* interrogate the command output.                        */
   Address Osf
   "OI PROGRAM(IST52I1) ARG("fromnode tonode") "
   

3. Specify one or more command output trapping keywords to override the default command response collection mechanisms. The required trapping keywords depend on how the command generates the command responses. Command responses can be any of the following:
   • Single MLWTO command responses
   • Multiple sets of MLWTO command responses
   • Individual WTO command responses
   • Command responses not directed back to the issuing console

   For examples of specific usage of the ADDRESS OPER for each type of command response, see the Example section.

4. Utilize the OPSLOG display columns OPSFLAGS and CONSNAME to determine the type of command response that is being generated.

   The values of the OPSFLAGS column identifies the message type (WTO, or MLWTO), and the CONSNAME column identifies if the responses are being directed back to the console that issued the command.

5. Determine the bit representations of the OPSFLAGS column by placing the cursor on the response line within the OPSLOG and hit enter.

   The Display All Columns for MSG Event pop-up panel displays.

6. Display the field descriptions by placing the cursor on the OPSF field and hit enter.

   The field description displays.

   For a description of each bit representation of the OPSFLAGS column, see the chapter “Message Rules” of the AOF Rules User Guide.