Workload Automation – Part 5a: Vexing Variables – parms

In the next part of this blog series we will look at variables used within TWS. This can be a confusing area especially for those long-time users of TWS as the use of “parameters” and “variables” is sometimes interchangeable. And that’s before we look at when variables get resolved – at job submission time or runtime.

Brief History of parameters and variables

Tivoli Workload Scheduler (TWS) has supported variable substitution in job definitions using parameters since the early versions of the software. TWS 8.3 redefined local parameters as global or local; global parameters being held in the TWS database and local parameters held local on the FTA.

The introduction of variable tables in TWS 8.5 redefined global parameters as variables and local parameters as parameters. Variables could now be defined within variable tables supporting both global (default) variables and job stream specific variables. TWS 8.6 then added support for runtime resolution of variables along with support for locally defined password and variable resolution for advanced job types.

TWS documentation refers to variables and parameters throughout, combined with global and local resolution options, all of which makes an already complex subject more difficult to comprehend.

Understandably, the different syntax for specifying parameters and variables can cause some confusion, particularly when considering different workstation types e.g. FTA, agent and different job types e.g. “traditional” or advanced job types. This in turn leads to difficulty in choosing the best option for variable substitution within the TWS job definitions. Understanding how each variable is specified and subsequently resolved should help to remove some of frustration encountered when variables do not resolve as expected.

Parameters

Starting with TWS 8.5, parameters, sometimes referred to as local parameters, are considered as a keyword and value pair held in a local database on each workstation where the job will execute. Parameters are managed using the TWS supplied “parms” command, which must be executed locally on the workstation to allow access to the local parameters database. Parameters can be resolved at job execution time or at job submission time depending upon the syntax used.

Local parameters can be resolved at

• submission time where the job or job stream is submitted on the FTA using conman
• at runtime on the FTA where the job executes

Local parameter values are managed using the “parms” command, which needs to be executed local to the FTA where the parameter value is to be used. To create a local parameter, use the following command on the FTA

This creates a local parameter named TESTPARM with a value of “parms database”.

Parameter Resolution

To resolve a parameter at job submission time, the value of the local parameter will only be used if TWS cannot resolve the value using a variable table. Variable table and variables resolution will be discussed in the next blog.

To resolve parameter values at runtime on the FTA, the “parms” command must be specified to invoke the command substitution function of the shell. An example is shown below

In the above example, the “parms” command prints the current value of the TESTPARM keyword as defined in the local parameters database. This relies upon the support for command substitution using the backticks functionality of the UNIX/Linux shell and is not supported natively in the Windows environment.

Summary

Advantages

Values can be resolved at execution time using the TWS “parms” command and the shell command substitution functionality (enclosed in backticks) e.g. TESTPARM=`/opt/IBM/TWA/TWS/bin/parms TESTPARM`

The TWS “parms” command can be used, as above, to supply different variable values for each FTA e.g. TESTPARM=CUST1 on FTA1 and TESTPARM=CUST2 on FTA2

The TWS “parms” command is supported in all TWS versions so can be safely used in environments with mixed TWS versions

Disadvantages

Command substitution by the command shell (i.e. backticks) is only fully supported on UNIX/Linux platforms. On the Windows platform a UNIX type shell e.g. Cygwin would need to be installed

Values can only be managed locally on each FTA using the “parms” command, so there is no centralised overview of the values set for each FTA

The example below shows the sample “parms” file contents used in this blog