Review the following:
You can use variables in Server Management to save time by more easily managing varying path information. For example, to globally control changes to the same location on all servers, you can use a variable for all volumes or drives in the script:
Create the variable in each server’s Subscriber object where the value of the variable is the server’s volume or drive where the location exists.
When the script runs, it passes the variable to each server, which in turn determines the variable’s value from the variable definition in its Subscriber object’s properties.
The value identifies which volume or drive contains the desired location.
Using a variable for this information, you didn’t have to individually list each server’s name with its volume or drive in the script.
Variables are used to simplify referencing something that is specific to individual servers or software run on servers. For example:
|
Destination Volumes or Drives |
Script contents to be executed |
|
DNS Names |
Server Names |
|
IP Addresses |
Working Directories |
|
Names of text files to be modified |
|
Each of these can have different data per server. Variables allow you to account for those differences easily.
Variables can be thought of as having three parts: name, value, and usage. The syntax for each is:
Name syntax: variable_name
Example: DEST
Value syntax: value_of_variable
Example: sys:
Usage syntax: %variable_name%
Example: %DEST%
Thus, the variable DEST would equate to sys: on the particular server where the variable is defined.
When defining a variable, you do not provide the % character for the variable’s name or value. However, when using the variable, you use the % character before and after its name.
The software uses the % character to identify the beginning and ending of variable names. For example:
%DEST% tells the software that DEST is a variable name.
The software looks up DEST in a variable definition table on the receiving server to discover its value.
The value is then used to complete the path.
You can nest variables to any level. For example, you can do the following to automate destinations:
Define DEST as the destination volume and directory:
Variable name: DEST
Value: %VOL_DRV%%DIR%
Here, you have nested two other variables inside of DEST to establish its value.
Usage: %DEST%
On a NetWare Subscriber, define the VOL_DRV variable:
Variable name: VOL_DRV
Value: attribute
For example, data:.
Usage: %VOL_DRV%
On a Windows Subscriber, define the VOL_DRV variable:
Variable name: VOL_DRV
Value: attribute
For example, C:.
Usage: %VOL_DRV%
Define the DIR variable:
Variable name: DIR
Value: attribute
A directory, such as \apps.
Usage: %DIR%
The result is that you can define the destination as simply DEST, which resolves to the directory and volume or drive specified at each target server. For example:
NetWare Subscriber: data:\apps
Windows Subscriber: c:\apps
The % symbol is a valid character for file and directory names. Therefore, you need to identify literal usage of a % character. Otherwise, the software would think a nested variable name was being provided.
Literal % characters are identified by adding an extra % character immediately before a % character in the variable’s value. This makes the software recognize the % character as a literal character and not a variable indicator. For example:
Variable name: DEST
Path for the variable: temp%abc%xyz
Variable value: temp%%abc%%xyz
The first % lets the software know that the next % character is literally part of the pathname, and not an indicator that a nested variable name is next. Without the double % characters, “abc” would be interpreted as a nested variable name.
General variable definitions, such as those in the Tiered Electronic Distribution policy, provide default variable values for Subscribers where they have none defined. Variables defined in a Subscriber object override such default variable values.
For Server Software Packages, variable names are resolved differently:
Is the variable defined in the Server Software Package component? If so, use that value.
IMPORTANT:A variable defined in a software package overrides any value defined in the Subscriber.
Is the variable one of the predefined variables? If so, use that value.
Is the variable a Java environment variable? If so, use that value.
Variables are checked for in a specific order to determine which variable to use. The order is:
Server Software Packages 1
Subscriber objects 1
Tiered Electronic Distribution policy 1
Default variables 2
Environment variables 2
1 User-defined in Server Management 2 Predefined
The variable is used from the first place where it is found.
Variables can also be used to specify where a Distribution is to be extracted, including the full path.
For example, you have a single Distribution with 20 Subscribers. You want to extract the Distribution to a specific volume on each of the Subscriber’s servers. However, the volume name varies from server to server: 15 servers are using the data: volume and five are using vol1:.
You can edit the Distribution Volume variable for some of these Subscribers by changing the Resolve To field on the Subscriber from data: to vol1: for the five Subscribers using that volume.
When the Distribution is extracted, it goes to the correct volumes on each of the 20 servers.