Creating a rule that includes a wait time before issuing command

[DavidJohnson]

Hello, 
I am not very good with REXX. I am being asked to create a rule to trigger when a msg PGTS0254E is issues. The request is for the rule to issue two commands when it sees this message and wait 10 seconds between issuing commands. The two commands are f XPCFU200,TCPTRON', then wait 10 seconds, then issue second command F XPCFU200,TCPTROF. Iv'e read that you can not do an opswait in a MSG rule as it can cause performance issues. How do I create rule(s) to accomplish this request? 
Thank you for your help.

[SAL COSTANZO]

You can spawn DYNAMIC TOD rules tor run. 1 to run in 10 seconds and 1 to run in 20 seconds.
DYNAMIC Rules are very helpful to automation and would be beneficial to learn.

You mentioned you are not good with REXX, but once you have the template for a Dynamic TOD RULE, building a REXX EXEC that would accept a DYNRULE NAME, a TIME(in seconds) and a COMMAND STRING, can then called by lots of code to delay commands.  Rules can OI the commands   
For Example:      if your rexx is called AFTERSEC,          OI AFTERSEC MYRULE 10 F XPCFU200,TCPTROF    

Hope that helps get started
Sal

[Dave Gorisek]

Based on the Cyberfusion message and commands you are asked to issue, looks as if this is a 'special' request to quickly obtain some internal debugging info to send to support. Thus, a ​quick and dirty rule to fire on the message, and issue the TCPTRON synchronously in the rule, then send out the TCPTROF command 10 seconds later is a simple temp solution. This can be done with the DELAY keyword on the OPSCMD in a server.
)MSG PGTS0254E                                        
)PROC                                                 
/* Issue cmd #1 synchronously in the rule */          
address Oper                                          
"C(F XPCFU200,TCPTRON) Nooutput"                      
/* Issue cmd #2 asynchronously in server via OPSCMD */
/* using DELAY keyword                              */
address TSO                                           
"OPSCMD C(F XPCFU200,TCPTROF) Delay(10) Nooutput"     


Again this is a quick solution.  You don't want to build on this type of logic as a permanent solution. The ideal automation for something permanent in addressing issuing cmd1 then cmd2 to the same asid (like these back to back cmds to Cyberfusion) is to have the firing rule trigger an OPS/REXX pgm to an OPS server (Address OSF "OI P(PGTS0254)") and then have logic in the pgm that issues cmd 1 and sets up trapping parms for the expected 'cmd response complete' msg before issuing cmd2. This of course is assuming that some 'all good' response is either sent back to the issuing console or directed elsewhere. So assume the TCPTRON cmd generates a PGT0111I  TCP TRACE IS ACTIVE (or whatever) back to the issuing console, the pgm would code:

Address OPER
"C(F XPCFU200,TCPTRON) Cmdwait(30) Stopresp(PGT0111I) Stopend(NO) Interval(0)"

So the pgm would wait for up to 30 secs or until PGT0111I is received (meaning ok to continue). When coding cmd1,cmd2,cmd3 you will have to interrogate the cmd response in the OPSLOG with the CONSNAME TIME MSGID columns displayed to see what the response are sent back. The doc for Address OPER describes in details how to determine the best trapping parms for any command where you need to interrogate the command output or issue a series of cmds to the same asid using some form of trapping parm. Various examples also exist in the ops.CCLXSAMP dsn that you can review such as SHUTCA7 and DB2THRD that you can use as a template to issue a cmd and trap the response back to the issuing console or non directed console response.



​​