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
/* 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
ALTDATEandALTTIMEDD parameters - allow a user to use the
$ALTDATEDD 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
ALTDATEandALTTIMEDD parameters - allow a user to use the
$ALTDATEDD 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'
DEFCMD,
DEFMSG, and DEFSMF cannot span control
cards; use multiple quoted text fields with a trailing +
to continue messages across cards.