Variable table definition

A variable table is an object that groups multiple variables. All the global parameters (now named variables) that you use in workload scheduling are contained in at least one variable table. Two ways of defining variables are available:
  • Define them when you define a variable table in the way described here. This is the recommended way.
  • Define them individually with the composer $parm command in the [tablename.]variablename “variablevalueˮ format. If you do not specify a table name, the new variable is placed in the default variable table.

You are not forced to create variable tables to be able to create and use variables. You might never create a table and never use one explicitly. In any case, the scheduler provides a default table and every time you create or manage a variable without naming the table, it stores it or looks for it there.

You can define more than one variable with the same name but different value and place them in different tables. Using variable tables you assign different values to the same variable and therefore reuse the same variable in job definitions and when defining prompts and file dependencies. Variable tables can be assigned at run cycle, job stream, and workstation level.

Variable tables can be particularly useful in job definitions when a job definition is used as a template for a job that belongs to more than one job stream. For example, you can assign different values to the same variable and reuse the same job definition in different job streams.

You can define one or more variables whose value contains another variable to allow dynamic variable substitution at run time. This feature makes your definitions more flexible, maintainable, and reusable.

You can nest any number of variables: the variables are resolved at run time in a recursive pattern, until they are all resolved. If a variable is not set, it is ignored and IBM® Workload Scheduler proceeds to the next variable, until the resolution process is completed.

Note: The following limitations apply:
  • This functionality is supported only for integrations running on dynamic agents. It is not supported on native job types.
  • The caret symbol (^) is not supported if you define the variable within a variable table. When defining nested variables within a variable table, you must use the ${variablename} syntax. However, both the caret symbol (^) and the ${variablename} syntax are supported when you reference the variable in the job definition of an integration running on a dynamic agent.

When creating a scheduling object, you can define it in a folder. If no folder path is specified, then the object definition is created in the current folder. By default, the current folder is the root (\) folder, but you can customize it to a different folder path. You can also use the composer rename command to move and rename objects in batch mode that use a naming convention to a different folder using part of the object name to assign a name to the object.

Syntax

vartable [folder/]tablename
[description “descriptionˮ]
[isdefault]
members
[variablename  “variablevalueˮ]
...
[variablename  “variablevalueˮ]
end

Arguments

vartable [folder/]tablename
The name of the variable table and, optionally, the name of the folder within which the variable table is defined. The name must start with a letter, and can contain alphanumeric characters, dashes, and underscores. It can contain up to 80 characters.
description “tabledescriptionˮ
The description of the variable table. The text must be enclosed within double quotation marks. The description can contain up to 120 alphanumeric characters. It cannot contain double quotation marks (") other than the enclosing ones, colon (:), semicolon (;), and ampersand (&).
isdefault
When specified, the table is the default table. You cannot mark more than one table as the default table. When you mark a variable table as the default variable table, the current variable table is no longer the default one. When migrating the database from a previous version, the product creates the default variable table with all the variables already defined.
members variablename “variablevalueˮ
The list of variables and their values separated by spaces. The name can contain up to 64 alphanumeric characters, including dashes (-) and underscores (_), and must start with a letter. The value can contain up to 1024 alphanumeric characters. Values must be enclosed within double quotation marks.
The following example shows a variable table and its contents. 
VARTABLE TEST1
  MEMBERS
   DEVBATCH "DOMD\IMSBATCH\SAME"
   PARAM_01 "date"
   PARAM_02 "root"
   PARM_01 "PARM_001"
   PRPT_02 "PARM_002"
   PRPT_03 "PARM_003"
   PRPT_04 "PARM_004"
   PRPT_05 "PARM_005"
   SAME17 "test/for/variable with samename > variable/table"
   SLAV10 "/nfsdir/billingprod/crmb/MAESTRO_JOB/AG82STGGDWHSCART"
   SLAV11 "/nfsdir/billingprod/crmb/MAESTRO_JOB/AG82CDMGALLBCV"
   SLAV12 "/nfsdir/billingprod/crmb/MAESTRO_JOB/AG82CDMGRISCTRAF"
   SLAV13 "/opt/crm/DWH_OK/Businness_Copy_ok"
   SLAV14 "/opt/crm/DWH_OK/DW_Canc_Cust_Gior_ok_"
   TRIGGER "/usr/local/samejobtriggers"
   VFILE2 "testforvarwithsamename2.sh"
   VUSER2 "same_user2"
   WRAPPER "/usr/local/sbin/same/phi_job.ksh"
END

Security file considerations

From the standpoint of security file authorizations, permission to act on the variable entries contained in a variable table is dependent on the overall permission granted on the variable table, as shown in following table.
Table 1. Required access keyword on variable table in Security file (vartable object) and allowed actions.
Required security file access keyword on enclosing variable table Allowed action on listed variable entries
Modify Add
Delete
Modify
Rename
Display Display
Unlock Unlock

See also

For more information about how to perform the same task from the Dynamic Workload Console, see:

Designing your workload.