Variables in parameter values

Many parameter values can optionally refer to variables.

IBM Z® Monitoring Configuration Manager supports the same variables as PARMGEN.

Tip: Instead of using variables, consider using LPAR-specific RTEDEF members.

Variables versus LPAR-specific RTEDEF members

Variables enable you to reuse a configuration profile member for different LPARs where LPARs require different parameter values.

However, using variables adds a precursor step to runtime environment started tasks. The step resolves variable values. The additional processing delays runtime environment startup.

LPAR-specific RTEDEF members, introduced by Monitoring Configuration Manager, offer an alternative to using variables for LPAR-specific parameter values.

Using LPAR-specific RTEDEF members instead of variables removes the variable-resolution precursor step from started tasks.

If you use LPAR-specific RTEDEF members instead of variables, started tasks are simpler and runtime environments start faster.

Using variables

To use variables, you must set the RTE_SYSV_SYSVAR_FLAG parameter to Y.

Variables, like parameters, are defined using name-value pairs and are stored in members of the RTEDEF library.

The following example, without variables, sets the parameter named RTE_TCP_PORT_NUM to the literal value 1918:

RTE_TCP_PORT_NUM 1918

The following example sets the parameter to the value of the variable RTE_PORT:

RTE_TCP_PORT_NUM &RTE_PORT.

Suppose your sysplex contains two LPARs: ZOS1 and ZOS2. In general, these LPARs have similar runtime environment configurations. However, on ZOS1 you want the monitoring server to listen on port 1918, whereas on ZOS2 you want the monitoring server to listen on port 1919.

In the variables configuration profile member for LPAR ZOS1, VAR$ZOS1, you set the RTE_PORT variable to 1918:

RTE_PORT 1918

In VAR$ZOS2, you set RTE_PORT to 1919:

RTE_PORT 1919

RTEDEF members that define variables

In the LPARs column of the following table, Current means: the LPAR on which the GENERATE action is performed.

Table 1. RTEDEF members that define variables, and the LPARs to which they apply
Member name	LPARs	Description
VAR$GLOB	All	Variables configuration profile.
VAR$`lpar`	Current	LPAR-specific variables configuration profile.

If a variable is defined in both VAR$GLOB and VAR$lpar, then the value in VAR$lpar is used.

Unique variable names

While Configuration Manager supports runtime environments with variables (parameter RTE_SYSV_SYSVAR_FLAG is set to Y), it does not support cases where the parameter value is a variable with the same name as the parameter itself.

For example, Configuration Manager does not allow the following parameter setting:

RTE_USS_RTEDIR &RTE_USS_RTEDIR

In this case, you must change the name of the variable to be different from the parameter name, as shown in the following example where the prefix MY_ has been added to the variable name:

RTE_USS_RTEDIR &MY_RTE_USS_RTEDIR

Variables migrated from PARMGEN

Unlike Configuration Manager, PARMGEN does allow the name of a variable to be the same as the parameter to which it is assigned. If any of these same-name settings exist in your PARMGEN parameter definitions, the variables must be renamed for use by Configuration Manager.

When you migrate configuration settings from PARMGEN to Configuration Manager using the MIGRATE action, the MIGRATE action automatically rectifies any such incompatible settings, as follows:

For variable names that are 30 characters or less, the MIGRATE action renames the variable by adding the following suffix to the name: _R
For example, PARMGEN allows the following parameter setting, which is defined in member WCONFIG(rte_name):
```
RTE_USS_RTEDIR &RTE_USS_RTEDIR
```
The value of the variable is set in member GBL_USER_JCL(rte_name), as follows:
```
RTE_USS_RTEDIR "value"
```
When the configuration settings are imported from PARMGEN to Configuration Manager, the MIGRATE action renames the variable, as follows:
- In member RTEDEF(rte_name):
```
RTE_USS_RTEDIR &RTE_USS_RTEDIR_R
```
- In member RTEDEF(VAR$GLOB):
```
RTE_USS_RTEDIR_R "value"
```
If the variable name is 31 characters, the MIGRATE action only adds the following suffix: _
If the variable name is 32 characters (the maximum length), the MIGRATE action only adds a comment with a warning in the respective RTEDEF(VAR$GLOB) member, indicating that you must rename the variable.

Note: To rename your variables to names other than those provided by the default naming convention of the MIGRATE action, you must manually rename the variables either before or after you run the MIGRATE action.