Rules development - syncsort_simulate_2000 - Latest

System and Local Rules

The DIF rules language is used by all DTS Software products. For system environments, DIF compiles the rules into data structures that reside in extended CSA. These rules are called System Rules, and are available for the products that get executed from multiple regions.

Other products that run in environments that don’t require rules spanning regions use rules called Local Rules. SIMULATE 2000 does not use local rules.

Location of Rules, Tables and Included Members

By default, the rule statements for each product are found in the partitioned data set allocated to the PARMLIB DD statement in the DIF started task: DTS.R71.RULELIB.

The PARMLIB DD statement is also used by the INCLUDE and TABLE statements. The INCLUDE and TABLE statements can partition the rules language into separate PDS members.

During product START or REFRESH processing, the rule statements are read from the PARMLIB PDS and converted into data structures that can be easily processed by the product. This conversion takes place in the DIF address space. After validation, the data structures are moved to extended CSA.

Separating Rules into Different PDS Members

All your installation rules can be grouped into one PDS member or distributed in separate PDS members. During rules conversion, INCLUDE statements can include control cards from other partitioned data set members.

For example, each logical group of rules could be created in its own member. If three individual rule members have been created, the following PTLRULES member could be used to compile all your installation rules:

INCLUDE RULE01
INCLUDE RULE02
INCLUDE RULE03
      

Transfer Control to Alternate Rule Members

The USERULES statement can transfer control to separate rule members. This facility might be useful for service bureaus or very large installations. Systems programming could control the product installation and global rule definitions, while different groups could be responsible for their own storage management.

For example, an installation that supports three companies might use account information to transfer control to separate rule members. During START or REFRESH processing, the rule compiler automatically converts the members specified by the USERULES operands. The rules language might perform installation-wide rule processing for standards enforcement, then use the following rule to pass control to the appropriate rules member:

DEFRULE XFERCNTL IF &ACCT EQ GD*
THEN USERULES(COMP01)
IF &ACCT EQ CF*
THEN USERULES(COMP02)
IF &ACCT EQ HE*
THEN USERULES(COMP03)
      

When the rules language transfers control to an alternate rules member, the primary member must be used by the product for the following conditions:

• The DEFENV statements are ignored for alternate rule members. The environment information is controlled by the primary member -- PTLRULES.

If you want to call another rules member and have control return to the calling rule, examine the CALLRULES statement later in this chapter.

Developing Rules

Develop your installation rules incrementally. It is not necessary to implement all your installation rules at once. Until you are familiar with the rules language, work on one rule at a time.

Any new rule should be enabled only for rule verification jobs. This can be performed by specifying the TEST parameter on the DEFRULE statement. Normal PTL rule processing will skip the new rule unless the rule verification job has allocated the PTLTEST DD statement.

Once the rule performs as designed, remove the TEST parameter from the DEFRULE statement. After the next START or REFRESH command, the new rule will be in production. For more information, examine “TESTING AND DEBUGGING” in the product’s user guide.

Syntax Errors — If you encounter syntax errors during rule conversion, the rule conversion process will display an error message with the member name and line number of the statement in error.

RULECKPT The Rule Checkpoint File

After the rule compiler successfully converts a rule member, the rule conversion process examines the DIF started task for the RULECKPT DD statement. If the checkpoint file is available, the rule compiler writes the converted rule member to the checkpoint data set: DTS.R71.RULECKPT.

For information about creating the checkpoint data set, see “Step 1 - Create the DIF production libraries” in the SIMULATE 2000 Product Installation Guide. A sample DIF DD statement follows:

//RULECKPT DD DISP=SHR,DSN=DTS.R71.RULECKPT
      

After checkpointing a rule, the compiler can recover from errors introduced to the rule statements at a later time. For example, an accidental change to the rules language that results in a compiler error at the next IPL can be recovered: during start processing, the compiler will report the problem and use the checkpoint data set to recover the last successfully compiled rule member.

This recovery process is only performed for rule problems that occur during product initialization. If you perform a REFRESH command after introducing an error to the rules, recovery from the checkpoint data set will not be performed.

Order of Rule Processing

When SIMULATE 2000 intercepts a TIME SVC or a CICS transaction, the rule definitions found in the rules language are evaluated. The rules are scanned sequentially after the allocation request is intercepted. Therefore, the order of the DEFRULE statements determines the order of rule evaluation.

For more information about redriving the rules language, examine the RULES(ALWAYS) parameter on the DEFENV statement, and the RESCAN symbolic field. Also, if the rules specify SET &ALLOW_DD=YES, the product will rescan for the special DD statements each time SIMULATE 2000 intercepts a time request (by default, SET &RESCAN=DD).