DEFVAR - 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 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.

Note:

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).

Note:

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

  • DEFVAR tag "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. The LITERAL 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