Defining rules - syncsort_simulate_2000 - Latest

Syncsort™ Storage Management Portal 2000 Rules Language Guide
Product type
Software
Portfolio
Integrate
Product family
Syncsort™ software
Product
Syncsort™ Storage Management > Syncsort™ Simulate 2000
Version
Latest
ft:locale
en-US
Product name
Syncsort Storage Management
ft:title
Syncsort™ Storage Management Portal 2000 Rules Language Guide
Copyright
2025
First publish date
1991
ft:lastEdition
2025-11-28
ft:lastPublication
2025-11-28T15:31:25.787000
L1_Product_Gateway
Integrate
L2_Product_Segment
IBM Infrastructure
L3_Product_Brand
Precisely Syncsort
L4_Investment_Segment
Mainframe
L5_Product_Group
Mainframe Storage Optimization
L6_Product_Name
Syncsort Storage Management

The DEFRULE statement defines a rule, and the rule definition may have one or more IF-THEN-ELSE groups. For clarity, a rule definition should use multiple IF-THEN-ELSE groups only when the groups are in some way related. The SIMULATE 2000 product uses these rule definitions to control processing.

The rule definitions may also point to a related operator command, message, SMF record definition, and other procedures. In other words, the DEFRULE statements really control SIMULATE 2000, and related DEFCMD, DEFMSG, DEFSMF and DEFPROC definitions provide support functions to the rule definitions.

Definitions merely provide support functions to the rule definitions.

The following structure details a typical rule definition. The relationships between a rule definition (DEFRULE) and the DEFCMD, DEFMSG, and DEFSMF are made with various parameters specified within IF-THEN-ELSE groups. The relationships and parameters will be covered in the following sections.

IF-THEN-ELSE_1
IF-THEN-ELSE_2
...
IF-THEN-ELSE_n
DEFCMD cmdname "text"
DEFMSG msgname "text"
DEFSMF smfname "text"

IF-THEN-ELSE Groups

A DEFRULE, DEFPROC or DO-END statement may have one or more IF-THEN-ELSE groups. The IF-THEN-ELSE groups are scanned in the order that they are presented in the rule or procedure definition.

The product evaluates the if_expressions found in the IF section of an IF-THEN-ELSE group. Once all conditions within the IF section of a group have been met, the product performs the action_statements specified within the THEN section. For more information about the conditional evaluation of the expressions, examine “Expressions” on page 3-20.

If any condition within an IF section fails and the ELSE parameter is specified, the actions specified by the ELSE section are performed. Otherwise, the next IF-THEN-ELSE group is evaluated within the rule definition. If no other IF-THEN-ELSE groups are specified for that DEFRULE, the first IF-THEN-ELSE group in the next DEFRULE statement will be evaluated.

Note: When using nested IF processing, consider keeping the logic as simple as possible to ease debugging and maintenance.

If nested IF processing is required, the rules language can use the DO-END or CALLPROC statements.

The following structure details a typical IF-THEN-ELSE definition.

IF

if_expression_1

if_expression_2

...

if_expression_n

action_statements flow_control_statements

ELSE

action_statements flow_control_statements

When requested by an IF-THEN-ELSE group, the rules language can take one or more of the following actions. For more information, examine “ACTION STATEMENTS” and FLOW CONTROL STATEMENTS.

  • set a modified date or time
  • allow a user to use ALTDATE and ALTIME DD parameters
  • allow a user to use the $ALTDATE DD statement
  • write execution audit records
  • write SMF records
  • write messages
  • issue operator commands
  • execute procedures — CALLPROC
  • execute DO-END statements
  • call an installation user exit — CALLEXIT
  • continue scanning at the next IF-THEN-ELSE, the next rule definition, or a specified rule definition
  • transfer control to another rules member — USERULES or CALLRULES
  • exit rule processing (EXIT), the current DO-END (EXITDO), or the current procedure (EXITPROC)

Debugging Your Rules

If a group of rules is not performing as intended, the language trace facility can be very helpful in determining the problem. If the PTLTRACE DD statement is allocated to a job or TSO user, the product will display messages when performing the compare operations. Adding the following DD statement to a job step will enable the rules language trace facility for the step. For more information, examine “TESTING AND DEBUGGING” in the product’s user guide.

//PTLTRACE DD DUMMY

Action Statements

Once the if_expressions found in the IF section of an IF-THEN-ELSE group are evaluated, and all conditions within the IF section of a group have been met, the product performs the requested action_statements and the flow_control_statements.

Action statements can also reside outside an IF-THEN-ELSE structure. For example, the DO-END and DEFPROC statements can issue action statements and not use conditional processing. For more information about each action statement, examine “ACTION STATEMENTS”.

The SET statement can use an expression to:

  • set a modified date or time
  • allow a user to use ALTDATE, ALTIME and PTLAUDIT DD parameters
  • allow a user to use the $ALTDATE DD statement
  • write execution audit records

The SET statement modifies the data field associated with a symbolic field name. Not all symbolic fields can be updated. The tables found in “SYMBOLIC FIELDS” on page 8-1 in the SIMULATE 2000 User’s Guide can be used to determine which fields can be modified.

The rules language has several symbolic fields that perform special functions. These fields support the alternate clock and audit requests. For a complete list of the symbolic fields that support product functions, examine “Symbolic Names for Internal Fields in the SIMULATE 2000 User’s Guide.”

After modifying a field, the SET statements can also write SMF records, messages to the user, and issue operator commands. These facilities are only invoked when the expression truly modifies the data.

Using ISSUE to Write Messages and SMF Records

The ISSUE statement can write SMF records, route messages, and issue operator commands. Since messages can be logged to a data set, the ISSUE statement can be used to monitor events that occur during SIMULATE 2000 processing.

The CALLPROC statement performs the procedure defined by a DEFPROC statement. A procedure has all the capabilities and characteristics of a rule definition with two exceptions.

  • Normal rule scanning does not process a procedure — another rule definition or procedure must request execution with a CALLPROC statement.
  • When IF processing successfully completes an IF-THEN-ELSE group within a procedure definition, the default continuation is an EXITPROC instead of an EXIT.

Both CALLPROC and DO-END statements can be used to implement nested IF processing, or execute a series of action statements. If your language contains multiple DO-END statements that perform the same function, you may wish to convert the DO-END statements to a single procedure and use the CALLPROC statement.

Using CALLREXX to Execute a Rexx Procedure

The CALLREXX statement can be used to transfer rule processing to a Rexx procedure. DIF provides functions that give the Rexx procedure access to all the DIF and product symbolic fields, as well as the ability to set the symbolic fields and route messages using DIF facilities. For more information, examine “Calling Rexx Procedures” on page 3-43.

The CALLRULES statement can be used to transfer rule processing to another rule member. The products obtain the installation and environment options from the DEFPROD and DEFENV statements found in the primary rule member — usually PTLRULES. By default, control will return to the calling rule when the alternate rule has completed execution. If you wish to transfer control to another rule, and do not wish to regain control, examine the USERULES statement on the next page.

Using DO-END to Execute In-Line Procedures

The DO-END statement is essentially an in-line procedure. The statement can be used to implement nested IF processing, or execute a series of action statements. A DO-END has all the capabilities and characteristics of a rule definition with one exception. When IF processing successfully completes an IF-THEN-ELSE within a DO-END definition, the default continuation is an EXITDO instead of an EXIT.

If your language contains multiple DO-END statements that perform the same function, you may wish to convert the DO-END statements to a single procedure and use the CALLPROC statement.

The USERULES statement can be used to transfer rule processing to another rule member. This facility might be useful for service bureaus, or very large installations.

SIMULATE 2000 obtains the installation and environment options from the DEFPROD and DEFENV statements found in the primary rule member — by default, PTLRULES. Once control is transferred to another rule member, control will not be returned to the caller.

Flow Control Statements

After performing all the action statements requested by an IF-THEN-ELSE group, the flow_control_statements can be used to terminate or continue rule processing.

Once an IF-THEN-ELSE group has successfully completed, the rules language can continue scanning at the next IF-THEN-ELSE, the next rule definition, a specific rule definition, or simply exit the rules language. By default, rules processing terminates after a successful IF-THEN-ELSE — no other IF-THEN-ELSE groups or DEFRULES will be scanned.

For more information about each flow control statement, examine “FLOW CONTROL STATEMENTS” .

Using CONTINUE to Keep Scanning

The CONTINUE parameter on the DEFPROD statement establishes the default continuation processing for the rules language. For exception processing, the CONTINUE parameter on the DEFRULE statement can override the default established by DEFPROD. Lastly, the CONTINUE flow control statement within THEN or ELSE processing can control rules statement processing.

  • When NEXTIF is specified, processing will continue with the next IF-THEN-ELSE group.
  • If NEXTRULE is specified, processing will continue with the first IF-THEN-ELSE group of the following DEFRULE statement.
  • If a rulename is specified, processing will continue with the first IF-THEN-ELSE group of the specified DEFRULE statement.
Note: In order to prevent looping within the rules language, the rule conversion program only allows scanning to continue at subsequent DEFRULE statements.

The CONTINUE statement does not have to be the last statement found in a THEN or ELSE section. The product processes the continuation request after completing all the action statements within the section.

By default, rules processing usually terminates after executing the action statements requested in a THEN or ELSE group — no other IF-THEN-ELSE groups or DEFRULES will be scanned. If the CONTINUE parameter on the DEFPROD or DEFRULE statements has modified the default, the EXIT flow control statement can be used in action processing to force termination of rule processing.

The EXIT statement does not have to be the last statement found in a THEN or ELSE section. The product processes the termination request after completing all the action statements within the section.

Using EXITDO to Terminate DO-END Statement

Once an IF-THEN-ELSE within a DO-END statement has successfully completed, the rules language can continue scanning at the next IF-THEN-ELSE group, exit the DO-END, or simply exit the rules language. By default, rules processing terminates the DO-END statement. Any subsequent action statements can then be processed, including additional DO-END statements.

EXITDO is only required when the CONTINUE parameter on the DEFPROD statement, the current rule definition or the current procedure has modified the default.

The EXITDO statement does not have to be the last statement found in a THEN or ELSE section. The product processes the termination request after completing all the action statements within the section.

Once an IF-THEN-ELSE within a procedure has successfully completed, the rules language can continue scanning at the next IF-THEN-ELSE group, exit the procedure, or simply exit the rules language. By default, rules processing terminates the procedure statement.

EXITPROC is only required when the CONTINUE parameter on the DEFPROD statement or DEFPROC statement definition has modified the default.

The EXITPROC statement does not have to be the last statement found in a THEN or ELSE section. The product processes the termination request after completing all the action statements within the section.