Rules language overview - 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

All software products use a common rules language for product customization. Each product typically has one or more rules members found in the PDS allocated to the PARMLIB DD statement in the DIF started task. By default, the data set name used throughout the documentation is DTS.R71.RULELIB. The default rule names follow:

PTLRULES Default rule name for SIMULATE 2000 ACCRULES Default rule name for ACC and SRS DSLRULES Default rule name for DLimit MONPOOLS Default rule name for Monitor

RTMRULES Default rule name for SCC Monitor/Realtime ABCRULES Default rule name for Application Backup Center SMSDEBUG Default rule name for SMS/Debug

The rules members contain the installation dependent setup options found on the DEFPROD control statement, and control logic defined by DEFRULE statements. The DEFRULE statements use IF-THEN-ELSE logic to control the product functions. These functions are usually executed by other rule statements. Messages, log records and SMF records are defined by DEFMSG, DEFREC and DEFSMF statements.

Rules are Compiled into Extended CSA

When a product is started by the Dynamic Install Facility (DIF started task), or a DIF REFRESH console command requested, the control cards for the rules are converted into data structures and placed in extended CSA. The compiled rules allow the products to scan the rules very quickly, and keep product overhead to a minimum.

Messages, Log Records, SMF Records, and Operator Commands

The rules language has facilities to produce messages, log records, SMF records, and operator commands. For example, when a TSO user attempts to allocate a data set to an improper volume, an ACC rule can be used to correct the request, and write a message explaining why the correction was made. Messages can be delivered in many ways. By default, batch jobs and started tasks receive messages via the JES message log, and TSO users receive messages by way of the TPUT SVC.

To monitor events that occur, the products allows copies of a message to be written to data sets, or sent to a specified TSO userid. To establish a more permanent audit trail, a rule can produce a log data set or SMF record for later examination.

Messages, log records, SMF records, and operator commands can be built using literal character strings and symbolic fields. The symbolic fields are substituted into the fixed text before issuing a command, or writing a message, log record or SMF record.

Tracing Facilities

When developing a rule it is often useful to examine the information used in the decision process. The rules tracing facility can be enabled with the use of special DD statements depending on the product: PTLTRACE, ACCTRACE, MONTRACE, DSLTRACE, EXTTRACE and SMSTRACE. This facility allows the person working on the rules language to view all the compare operations that occur during rule processing. For more information, examine the “TESTING AND DEBUGGING” chapter in the appropriate product manual.