The DEFVAR statement defines a new variable in the rules language. The value of the new variable is typically constructed with using other variables and literal fields.
However, the value of the new variable can also be obtained using an operator prompt, read from a record in a KSDS VSAM file, obtained from a system symbol, or set from a field in a record from a keyed table.
The DEFVAR statement allows indirect references to other variables — even
other variables created with DEFVAR. For a typical example of a
DEFVAR statement, Monitor might use the following
definition in the rules language.
DEFVAR VOLUME_ACTION "&VOLSER.-ACTION" SYSTEM
The statement defines a new variable in the rules called VOLUME_ACTION. The
rule language can access this new variable like any other symbolic field. When the rules are
executing and the language references VOLUME_ACTION, the rules processor will
perform substitution to build the new variable.
For example, the following SET statement assigns DEFRAG to
the variable. The new variable is actually a combination of the current volume being processed
by rules, and the literal -ACTION. The DEFVAR statement tags
this new variable with the name VOLUME_ACTION. While the rules always
reference this tag, the language is actually building the name whenever the tag is encountered
during rule execution.
SET VOLUME_ACTION = DEFRAG
The new variable can have a scope of LOCAL or SYSTEM.
SYSTEM scope and VSAM
The SYSTEM parameter used in the sample allows the rules processor to
write the new variable to a VSAM file during SET processing. The KSDS VSAM
file has two fields in each record: the key being the generated name and the value. If the
current &VOLSER at rule execution is STOR04, the
SET statement in the example would produce a VSAM key of
STOR04-ACTION with a value of DEFRAG.
Variables with a scope of SYSTEM are only available for products running
in non-authorized environments.
LOCAL variables are available for all environments, but the variables are only available during rule execution.
Building the Text field
The DEFVAR statement builds the new variable with the use of literal
strings and symbolic substitution. The text field must start with a single (') or
double quote (“), and terminate with the same type of quote. Both character and numeric
symbolic fields can be placed in the definition. For more information, examine “Symbolic Fields”.
Continuation
The variable definition cannot be continued onto the next card. Add a plus
(+) sign after the end of the text field, and start another quoted text
field on the next control card. Message length after substitution is limited to 125 bytes.
For more information, examine “Continuation” .
Defining a VSAM file for SYSTEM variables
The following JCL allocates and initializes a VSAM file for variables with a scope of
SYSTEM. The file should be allocated to the DEFVAR DD
statement in any job that accesses the variable. These are typically jobs executing
SCC Monitor.
//JOBNAME JOB ... (RC=0 Expected)
//EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//IN DD *
$DUMMY
//SYSIN DD *
DELETE DTS.R71.DIFVAR
DEFINE CLUSTER(NAME(DTS.R71.DIFVAR) + VOLUME(??????) SHAREOPTIONS(2) + RECORDSIZE(56 254) CYL(2 2) + INDEXED KEYS(52 0) )
REPRO INFILE(IN) OUTDATASET(DTS.R71.DIFVAR) LISTCAT ENTRY(DTS.R71.DIFVAR) ALL
Prompting the Operator
The DEFVAR statement can also be used to establish a link between the new
variable and the console operator by using the OPERATOR parameter. During
rule execution, if a rule tries to access a defined variable and the
OPERATOR parameter has been specified, the product will
WTO/WTOR all the messages defined by the
OPERATOR(WRITEMSG) parameter — the last message in the list will use a
WTOR. The operator reply will be placed in the variable defined by
DEFVAR.
Accessing the System Symbols
The DEFVAROPSYS parameter can access the static and dynamic system symbols. For
information on system symbols as well as a list of the dynamic system symbols, examine
chapter 2 in z/OS MVS Initialization and Tuning Reference (IBM manual SA22-7605).
Also, the static system symbols can be displayed with the following console command:
D SYMBOLS
The DEFVAR statement can be used to dynamically create a DIF symbolic
variable which can be used by the product rules language. For example, the following
DEFVAR statement creates REZPACK based on the
&SYSR1 field typically found in
SYS1.PARMLIB(IEASYMnn).
The "$SYSR1" specified is not a typo. The $
differentiates the system symbol from the symbolic fields used by the products.
DEFVAR REZPACK "$SYSR1" OPSYS
The REZPACK symbolic field can now be accessed in the rules language. For
example:
DEFRULE ALLOCREZ
IF &REZPACK = 'Z1RSA1' THEN ...
Reading Records from a Keyed Table
The DIF DBIO command along with a file definition can be used to load
keyed tables. The command builds an index for the record keys in a data space. The records
in the table can also be loaded into a data space or be left on disk. The rules language can
then be used to look-up entries in the table and retrieve fields from records.
How do the rules access records in a keyed table? First, one or more
DEFVAR statements should be added to your rules to define symbolic names
to access information from the keyed table. At run-time, when your rules use the new
symbolic names, the rule processor will use the key:field_name in
vardefn to get the requested field from the keyed table. For more
information, examine “Expressions” on page 3-20.
Note: Before the rules can use the keyed table, the DIF DBIO command must
be used to load the table into a data space. For more information, examine “DBIO” on page
7-9 in the Product Installation Guide.
In the following sample rule statements, three DEFVAR statements are used
to define the FLDn variables. The first DEFVAR uses
literals to assign the value of the specified RR_F4 field to the
FLD2 variable. The second uses the current data set name as the key, with
the field name being fixed. The last DEFVAR performs symbolic substitution
on both the key and field name. In the example, a DEFMSG is used to display
the information.
However, the FLDn symbolic names can be used by any rule statements that
support symbolic field names.
DEFVAR FLD2 "TOM.TESTDATA:RR_F4" DBIO(TABLERR)
DEFVAR FLD3 "&DSNAME.:RR_F2" DBIO(TABLERR)
DEFVAR FLD4 "&DSNAME.:&USRFLDC1(1,8)" DBIO(TABLERR)
...
DEFMSG E1 "&FLD2 - &FLD3 - &FLD4"
DEFVAR statement syntax summary
-
DEFVARtag "vardefn" [scope] [type] -
DBIO(tablename)LITERAL -
OPERATOR(blanks) -
PROMPT(option) -
WRITEMSG(name1,name2,...) -
OPSYS -
WILD
Function: The tag defines the name of the new variable used in the rules language. Other rules constructs can access the variable by using this name. While the tag is actually coded in the rules language, during execution the rules processor uses the vardefn parameter to build the true variable name.
The DEFVAR statement can use a special statement name to establish
parameter defaults. When $DEFAULT is specified, the rule compiler uses the
specified parameters to modify the parameter defaults for later DEFVAR
statements. For more information, examine “Using $DEFAULT on Statement Definitions” on page 3-42.
Default: None
Format: Specify a name 1 to 20 characters long.
"vardefn"
Function: The vardefn parameter is used to define the new variable created for the rules language. This parameter can use both literal strings and symbolic substitution to build a new variable. The vardefn field must start with a single (') or double quote (“), and terminate with the same type of quote. Text that requires the internal use of a quote should use the opposite type for the text delimiters.
If the DBIO parameter is also specified on the DEFVAR
statement, the vardefn is a key:field_name request used for keyed tables.
The key is the look-up value, and the field_name selects one of the field
names defined in the file definition used by the DIF DBIO command. Symbolic
names can be used in the key:field_name information. However, when symbolic names
are specified in the key:field_name, the name must be terminated with a period. For
more information, examine “Expressions”.
The variable definition field cannot be continued onto the next card. Add a plus
(+) sign after the end of the terminating quote, and start another quoted
variable definition field on the next control card. Variable definition length after
substitution is limited to 125 bytes.
Default: None
Format: "vardefn" or 'vardefn'
scope
Function: The scope parameter determines whether the variable can be used
outside the rules language. By default, the variable has a scope of LOCAL,
and only the rules language can access the variable. If SYSTEM is
specified, the variable will be backed by a VSAM file, and external access to the variable
is available.
Default:
LOCAL
Format:
-
LOCAL -
SYSTEM
type
Function: The type parameter determines whether the new variable is
considered a character or numeric symbolic field. By default, new variables are considered
CHARACTER fields.
Default:
CHARACTER
Format:
-
CHARACTER -
NUMERIC
DBIO (tablename)
Function: The tablename parameter specifies a keyed table name used to obtain the key:field_name request requested by the vardefn positional parameter. The key is the look-up value. The rules processor will binary search the index of the requested tablename, and set the value of the new variable name (tag) with the information obtained from the requested field in the record. Field names are defined in a file definition DIF parmlib member. For more information, examine “DBIO” on page 7-9 in the Product Installation Guide. For more information, examine “Expressions” on page 3-20.
Default: None
Format:
DBIO ( tablename )
LITERAL
Function: Normally, the vardefn parameter performs symbolic substitution to build a new variable. TheLITERAL parameter can be used to leave the
symbolic name in the variable definition. For example, the following DEFVAR
and IF statement can be used to determine if the current jobname followed
by a period is found in the current data set name.
DEFVAR TEMPFLD1 "*&JOBNAME.*" LITERAL
IF DSNAME = &TEMPFLD1
Default: None
Format:LITERAL
OPERATOR parameter
Function: The OPERATOR parameter establishes a link between the new
variable and the console operator. During rule execution, if a rule tries to access the
defined variable and the OPERATOR parameter has been specified, the product
will WTO/WTOR all the messages defined by the
OPERATOR(WRITEMSG) parameter — the last message in the list will use a
WTOR. The operator’s reply will be placed in the variable defined by
DEFVAR.
The NOBLANKS determines whether the operator can enter a blank response.
By default, the NOBLANKS operand will not return control to the rules until
the operator has returned a non-blank response.
Default:
NOBLANKS
Format:
-
BLANKS -
NOBLANKS
OPERATOR(...PROMPT(option))
The PROMPT(NULL) operand can be used to test the current value of a
variable, and only prompt the operator if the variable is blank for character fields, or
zero for numeric fields. If PROMPT(ALWAYS) is specified, the operator will
always be prompted.
Default:
PROMPT(NULL)
Format:
-
PROMPT(ALWAYS) -
PROMPT(NULL)
OPERATOR(...WRITEMSG(name))
Function: The OPERATOR parameter establishes a link between the new
variable and the console operator. During rule execution, if a rule tries to access the
defined variable and the OPERATOR parameter has been specified, the product
will WTO/WTOR all the messages defined by the
OPERATOR(WRITEMSG) parameter — the last message in the list will use a
WTOR. The operator’s reply will be placed in the variable defined by
DEFVAR.
The message(s) specified on the WRITEMSG parameter are defined by
DEFMSG statements. The WTODC parameters can be used to
stick the messages on the console. Once the operator replies, all the messages associated
with the WRITEMSG will be deleted, which allows the messages to scroll.
Default: None
Format:
-
WRITEMSG(name) -
WRITEMSG(name1,name2,...)
OPSYS parameter
Function: The OPSYS parameter can be used to create a new symbolic
field that obtains the field value by accessing the system symbols. For information on
system symbols as well as a list of the dynamic system symbols, examine chapter 2 in
z/OS MVS Initialization and Tuning Reference (IBM manual SA22-7605). Also, the
static system symbols can be displayed with the console command D
SYMBOLS.
The DEFVAR statement can be used to dynamically create a DIF symbolic
variable which can be used by the product rules language. For example, the following
DEFVAR statement creates REZPACK based on the
&SYSR1 field typically found in
SYS1.PARMLIB(IEASYMnn).
Default: None
Format:
OPSYS
WILD
Function: The WILD parameter determines how the rules execution
routines treat wildcard characters found in the variable. For example, if the variable
contains the string STOR* and WILD is specified, the
expressions that use the variable will perform pattern matching. If NOWILD
is specified, no pattern matching is performed during evaluation.
Note: the wildcard characters are asterisk (*) and question mark
(?).
Default:
NOWILD
Format:
-
WILD -
NOWILD