General Information

When the DO RULE statement is encountered during rule processing, Control-M/Analyzer invokes the specified rule. When the specified rule finishes processing, processing flow continues sequentially from the point after the DO RULE statement in the calling rule.

Rule recursion (for example, a rule calling itself), whether explicit or implicit, is not permitted. A runtime error occurs when recursion is detected.

The called rule is read from the libraries referenced by the DABRULE DD statement.

The return code of the called rule is placed in System variable SYSRC.

The calling rule may pass variables as input to the called rule, as explained above. These variables are called rule arguments. Rule arguments must be Local or Database variables that have already been initialized. The called rule may change the values of these arguments, causing the new values to be returned to the calling rule.

The called rule refers to these arguments by specifying the RARGnn parameter, where nn is a number from 1 to the actual number of passed arguments.

Control-M/Analyzer AutoEdit variables plus Local and Database variables (preceded by the %% prefix) can be embedded in the ARG parameter of the DO RULE statement. The variables are resolved (replaced) at time of rule execution. For additional information on AutoEdit processing, see Control-M/Analyzer Variables, and in particular Passing Variables to Blocks, Rules and User Routines.

Control-M/Analyzer Database variables are committed (according to the method specified in the DO COMMIT statement) when the rule terminates.

• If the rule was called by a job step, commitment occurs when the rule terminates.
• If the rule was called by another rule (by the DO RULE statement), commitment occurs when the calling rule terminates.

After termination of the called rule, processing flow control returns to either the next step (in the job that called the rule) or the calling rule – depending on that entity invoked the called rule.