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.

Syntax

Arguments

vartable tablename

The name of the variable table. 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 quotes. The description can contain up to 120 alphanumeric characters. It cannot contain double quotes (") 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. Values must be enclosed within double quotes.

Example

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.

See also

To create a variable table definition in the Tivoli Dynamic Workload Console:

1. Click Tivoli Workload Scheduler→Workload→Design→Create Workload Definitions
2. Select an engine name and click Go
3. In the Working List toolbar of the pop-up window that opens, click New→Variable Table
4. Specify your choices in the Properties - Variable Table panel.

• Related information
• Customizing jobs and job streams based on when they are scheduled to run
  This scenario shows how to customize jobs and job streams based on when they are scheduled to run, that is on which days they run, using variable tables referenced at the run cycle level.
• Customizing jobs and job streams based on why they are scheduled to run
  This scenario shows how to customize jobs and job streams based on why they are scheduled to run, for example to create a job that runs different commands for different users, referencing different variable tables at job stream level.
• Customizing jobs and job streams for submission
  This scenario shows how you customize jobs and job streams for submission, for example, to submit a job that runs different data when a specific event occurs in your workload environment.
• Customizing jobs and job streams based on where they are scheduled to run
  This scenario shows how to customize jobs and job streams based on where they run, for example, on different workstations, using variable tables with workstations.

[ Top of Page | Previous Page | Next Page | Contents ]