Rules language - 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 rule language is comprised of control cards. The control cards are 80 byte records. If columns 73-80 contain numeric characters, the line numbers will be ignored.

The control cards can be one of the following:

  • blank lines
  • comments
  • rule statements

Rule Compilation

When SIMULATE 2000 is started by DIF, or an operator issues a REFRESH command, the rules compiler will read the control cards from PTLRULES. As previously discussed, PTLRULES is a member of the partitioned data set allocated to the PARMLIB DD statement in the DIF started task.

The compiler will ensure that the control cards are syntactically correct. The compiler will also validate the relationships between the control cards. For example, if a DEFRULE statement uses the WRITEMSG parameter, the compiler will ensure that a DEFMSG statement exists for the requested message.

After validating the control cards, the compiler will then move the data structures created from the control cards into extended CSA. The rules compiler then deletes the old rules from extended CSA.

Comments The character string /* starts a comment block. The rules compiler will ignore all information found within a comment block. Comments can span control cards, or share the control card with a statement. The comment block is terminated with the */ character string.

/* comment card */

The rules language also accepts two other forms of comment. Any control card starting with an asterisk (*), or //*, in the first column are considered comment cards.

* This is a comment card
//* This is a comment card
Note: Comment blocks using /* and */ can be nested. The rules compiler will only process information found outside all nested comment blocks.

For example, since the following DEFENV statement resides inside a comment block, the rules statement would not be processed during rules conversion.

/* /* comment card */ DEFENV EXEC MODE(ACTIVE) */

Statements Overview

The “RULES LANGUAGE REFERENCE” on page 5-1 provides a detailed reference of the rule statements and parameters. This section summarizes each of the statements. While the statements can be placed in any order in the rules language, the summary below lists them in the order used by the sample rule members found in the installation library.

DEFPROD The DEFPROD statement defines installation dependent information required by the products. This statement is usually the first statement found in the rules language. Since all parameters on the statement have defaults, the DEFPROD statement is not required.

DEFENV The DEFENV statement defines which system interfaces available to a product are required by your installation. Each environment has unique capabilities. For more information, examine “Test Environments and the Rules Language” on page 4-29 in the SIMULATE 2000 User’s Guide.

DEFLIST The DEFLIST rules statement provides an easy way to exclude programs from product processing in multi-tasking environments like TSO. For more information, examine “Excluding Programs that Make Clock Requests” on page 4-32.

DEFLMOD The DYNAMOD option allows the product to interface with the operating system facility responsible for loading programs into memory. During the load process, SIMULATE 2000 scans selected programs for instructions that access CVTDATE, or issue the STCK instruction. The product can then patch the program in memory to allow the use of alternate clocks. The DEFLMOD statement defines the programs that should be processed by DYNAMOD.

DEFCONN Messages and records written by the rules language can be directed to an MQSeries message queue, the System Logger, a network syslog daemon, or directly to an HFS file using the DEFCONN rules statement.

The DEFCONN statement maps the DDname requested by the WRITEREC and WRITEMSG statements to an MQSeries message queue, logger stream name, syslog server, or HFS file name. Local and remote computers that have access to the message queue can retrieve messages. The DIFMFPRT program can be used to extract messages and/or records from the system logger streams. For more information, examine The Message Facility Print Program - DIFMFPRT.

The DIF started task can also be used as a gateway to the MQSeries message queues or the system logger streams. The rules language can write messages to the log files in the DIF started task. By using DEFCONN commands, DIF can redirect or copy the log message to the message queue or system stream name. For more information about the interface and configuration, examine “DEFCONN”.

DEFEQU The DEFEQU statement can be used to equate an installation-definable symbolic name with a literal value or another symbolic field. Substrings are supported on character symbolic fields, and numeric symbolic fields can be defined by specifying the NUMERIC parameter before the equate expression.

This facility can be used to assign meaningful names to the user fields delivered with SIMULATE 2000: USRFLDCn and USRFLDNn. Also, since the expressions on the DEFEQU statements support substrings, a single user field can be subdivided into many new symbolic fields.

DEFVAR The DEFVAR statement defines a new variable in the rules language. A new variable is typically constructed using other variables and literal fields. The DEFVAR statement allows indirect references to other variables — even other variables created with DEFVAR.

DEFRULE The DEFRULE statement defines one or more rules — IF-THEN-ELSE groups. The rules are scanned sequentially. By default, once an IF group is successfully processed, the related THEN or ELSE group is processed and scanning will terminate. To continue scanning, the CONTINUE operand can be specified in the rule definition or on the DEFPROD statement. The rules can be used to perform one or more of the following functions:

  • set a modified date or time
  • allow a user to use ALTDATE and ALTTIME 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

DEFMSG The DEFMSG statement defines a message. Messages can be delivered in a variety of ways. TSO users usually receive messages via the TPUT SVC interface. Batch jobs and started tasks usually receive messages via the JES message log. IDCAMS allocations get messages via the SYSPRINT DD statement.

The DEFMSG statement only defines the message. Other rules statements actually request that the message be issued. These other statements use the WRITEMSG operand to invoke and control message processing.

DEFSMF The DEFSMF statement defines an SMF record. Other rules statements actually request that the SMF record be issued. These other statements use the WRITESMF operand to write the SMF records.

DEFCMD The DEFCMD statement defines an operator command that can be issued by the rules language. The DEFRULE statements use the OPER-CMD parameter to actually issue the operator command defined by DEFCMD.

DEFREC The DEFREC statement defines a record that can be written by the rules language. The DEFRULE statements use the WRITEREC parameter to actually write the record defined by DEFREC.

DEFPROC The DEFPROC statement defines a procedure that can be used as an extension to a rule. The DEFRULE statement, or another procedure, can use the CALLPROC parameter to execute a procedure definition. Like DEFRULE, the DEFPROC statement can be used to perform one or more of the following functions:

  • set a modified date or time
  • allow a user to use ALTDATE and ALTTIME DD parameters
  • allow a user to use the $ALTDATE DD statement
  • write execution audit records
  • write SMF records
  • write messages
  • issue operator commands
  • execute other procedures (CALLPROC)
  • execute DO-END statements

INCLUDE The INCLUDE statement copies statements from the member name(s) specified on the INCLUDE statement. The compiler obtains the member(s) from the PARMLIB DD statement allocated in the DIF started task.

One or more member names can be specified on each INCLUDE statement. Multiple names can be enclosed in parentheses, and commas or blanks are used to delimit the member names. Comments can be added by specifying the /* and */ control characters.

Continuation In almost all cases, continuation is not a problem with the rules language. Simply continue parameters for a statement on the next control card. For example, to continue the list of job names in the following definition, just continue the list on the next line.

DEFRULE PRDDATE
IF JOBNAME = (PRD001,PRD006,PRD009,PRD011,PRD032,PRD049,PRD055)
THEN SET ALTDATE = 2001.001

The text fields on the DEFCMD, DEFMSG and DEFSMF statements provide the one exception for continuation. These fields must start and end on the same control card. To produce a long message, multiple text fields can be specified. To continue a message, add a plus (+) sign after the end of one text field, and start another quoted text field on the next control card.

DEFMSG PTLMSG01 'THIS IS A VERY LONG MESSAGE ' +
'THAT CAN ONLY BE HANDLED BY ' + 'MULTIPLE TEXT ENTRIES'
Note: Remember: text fields for DEFCMD, DEFMSG, and DEFSMF cannot span control cards; use multiple quoted text fields with a trailing + to continue messages across cards.