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
[twsuser@clynelish TWS]$ /opt/ibm/TWA/TWS/bin/parms -c TESTPARM "parms database" [twsuser@clynelish TWS]$
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
[twsuser@clynelish TWS]$ conman sj CLYNELISH#JOBS.ORB_FTA_TESTPARM\;stdl IBM Workload Scheduler(UNIX)/CONMAN 9.4.0.01 (20170626) Licensed Materials - Property of IBM* and HCL** 5698-WSH (C) Copyright IBM Corp. 1998, 2016 All rights reserved. (C) Copyright HCL Technologies Ltd. 2016, 2017 All rights reserved. * Trademark of International Business Machines ** Trademark of HCL Technologies Limited Installed for user "twsuser". Locale LANG set to the following: "en" Scheduled for (Exp) 17/11/14 (#2156) on CLYNELISH. Batchman LIVES. Limit: 10, Fence: 85, Audit Level: 1 %sj CLYNELISH#JOBS.ORB_FTA_TESTPARM;stdl =============================================================== = JOB : CLYNELISH#JOBS[(0000 17/11/12),(JOBS)].ORB_FTA_TESTPARM = USER : twsuser twsuser = JCLFILE : /bin/echo TESTPARM was resolved from `/opt/ibm/TWA/TWS/bin/parms TESTPARM` = Job Number: 23872 = Tue 11/14/17 12:12:33 GMT =============================================================== TWS for UNIX/JOBMANRC 9.4 AWSBIS307I Starting /opt/ibm/TWA/TWS/jobmanrc /bin/echo TESTPARM was resolved from `/opt/ibm/TWA/TWS/bin/parms TESTPARM` IBM Workload Scheduler(UNIX)/JOBINFO 9.4.0.01 (20170626) Installed for user "twsuser". Locale LANG set to the following: "en" TESTPARM was resolved from parms database AWSBIS308I End of job =============================================================== = Exit Status : 0 = System Time (Seconds) : 0 Elapsed Time (hh:mm:ss) : 0:00:00 = User Time (Seconds) : 0 = Tue 11/14/17 12:12:33 GMT =============================================================== [twsuser@clynelish TWS]$
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
[twsuser@clynelish TWS]$ parms -e /tmp/parms.txt;cat /tmp/parms.txt $PARM LOCAL_DATE "2017-11-09" SOURCE "clynelish.scotchwhisky.local" TESTPARM "parms database" TESTUSER "twsuser" [twsuser@clynelish TWS]$
The next blog in the series will look at TWS variables as used with Variable Tables.
Visits: 162
