Variable and parameter definition
Variables and parameters are objects to which you assign different values.
Variables and parameters are useful when you have values that change depending on your job streams and jobs. Job stream, job, and prompt definitions that use them are updated automatically either at the start of the production cycle or at the time the job runs depending on the format used when the variable is specified.
Use variables and parameters as substitutes for repetitive values when defining prompts, jobs, and job streams. For example, using variables for user logon and script file names in job definitions and for file and prompt dependencies permits the use of values that can be maintained centrally in the database on the master.
While variables are scheduling objects that are defined in the HCL Workload Automation database and can be used by any authorized users in the domain, parameters are defined and used locally on individual agents.
The following sections describe variables and parameters in detail.
Variables
$parm
[tablename.][folder/]variablename “variablevalue”
...
- tablename
- Is the name of the variable table that is to contain the new variable. The variable table must be already defined. If you do not specify a variable table name, the variable is added to the default table.
- [folder/]variablename
- Is the name of the variable, optionally preceded by the folder name within which the variable table is defined. The variable table name can contain up to 64 alphanumeric characters, including dashes (-) and underscores (_), and must start with a letter.
- value
- Is the value assigned to the variable. The value can contain up to 1024 alphanumeric characters. Do not include the names of other variables.
However, the recommended way to define variables is to use a Variable table definition. In any case, all variables are placed in a variable table. If you define a variable and do not specify the name of a variable table, it is included in the default variable table.
- ^variablename^
- Specify the variable in this format if you want it resolved when the plan is generated or extended.
- ${variablename}
- Specify the variable in this format if you want it resolved or overwritten when the job or job
stream is submitted to be run. An option in the job definition that indicates to resolve variables
at the job run time must also be specified. If this variable is present only in the default variable
table, the variable cannot be resolved. See an example of an application of this kind of variable in
the section Examples.Attention: When submitting a job stream from the Self-Service Catalog that contains variables or that has a variable table associated to it, variables specified in this format, ${variablename}, are not supported. They must be specified in the ^variablename^ format.
For details on variable resolution, see Variable resolution.
The variable names specified in these definitions are first resolved against variable table definitions and then on local parameters if the variables are not found.
When you specify a variable, enclose the entire string containing the variable in
quotation marks (" ")
.
\^
sequence
could be wrongly interpreted as an escape sequence and resolved by
the parser as caret character. If necessary, move the backslash into
the definition of the variable between carets to avoid bad interpretation
of the backslash character. For example, the following table shows
the correct way for defining and using a variable named MYDIR
in
the default variable table: Wrong way | Right way |
---|---|
|
|
Parameters
Local parameters are defined in a local database on the workstation where the jobs using them will run. To define them, you do not use this composer command but the parms utility command.
- JCL
- Log on
- Prompts dependencies
- File dependencies
- Recovery prompts
'bin\parms PARAMETERNAME'
- At run time on the workstation where job processing occurs.
- At submission time on the workstation where the job or job stream is submitted from the
conman command line. Keywords that can take local parameters in submit commands summarizes in which
submit command keyword you can use parameters.
Table 2. Keywords that can take local parameters in submit commands Keyword submit docommand (sbd command) submit file (sbf command) submit job (sbj command) submit job stream (sbs command) abendprompt ✓ ✓ ✓ scriptname ✓ docommand ✓ logon ✓ ✓ opens ✓ ✓ ✓ ✓ prompt ✓ ✓ ✓ ✓ For more information on how to submit jobs and job streams in production from the conman command line refer to Managing objects in the plan - conman.
path/parms parametername
between ' '
characters to ensure the parameter is solved at run time on the workstation even if a parameter with
the same name is defined as a global parameter in the HCL Workload Automation database. For example, if you add to the
database the following job definition:
$jobs
myjob
docommand "ls ^MYDIR^"
streamlogon "^MYUSER^"
and two
parameters named MYDIR
and MYUSER
are defined in the database,
then, as the production plan is created or extended, the two parameters are resolved using the
definitions contained in the database and their corresponding values are carried with the
Symphony
file. If you define in the database myjob
as follows:
$jobs
myjob
docommand "ls 'bin/parms MYDIR'"
streamlogon "'bin MYUSER'"
then
as the production plan is created or extended the only action that is performed against the two
parameters in the definition of myjob
is the removal of the ' ' characters, the
parameters are carried in the Symphony
file unresolved and then are resolved at run
time locally on the target workstation using the value stored in the PARMS database.Examples
Two parameters, glpah
and gllogon
,
are defined as follows:
$parm
glpath "/glfiles/daily"
gllogon "gluser"
The glpath
and gllogon
parameters
are used in the gljob2
job of theglsched
job
stream:
schedule glsched on weekdays
:
gljob2
scriptname "/usr/gl^glpath^"
streamlogon "^gllogon^"
opens "^glpath^/datafile"
prompt ":^glpath^ started by ^gllogon^"
end
docommand "ls ^MY_HOME^"
<jsdle:script>echo ^SWITCH_VAR^:${SWITCH_VAR}</jsdle:script>
The
order in which these jobs run is the
following:SCHEDULE NC117126#PROCJS
VARTABLE STATETABLE
:
NC117126_1# PROC1
NC117126_1# PROC2
FOLLOWS UPDATE1
NC117126_1# UPDATE1
FOLLOWS PROC1
END
When
the job stream is added to the plan, SWITCH_VAR, defined in both PROC1
and PROC2, immediately assumes the default value assigned in the variable table,
on. When the job stream is submitted to be run, the first job to be
submitted is PROC1 and the variable defined as SWITCH_VAR is resolved to
on so that the variables in the PROC1 job are resolved
as:<jsdle:scriptecho>on:onjsdle:script>echo on:on</jsdle:script>
UPDATE1
then runs setting the value of SWITCH_VAR in the variable table to
off so that when PROC2 runs, the variables are resolved
as:<jsdle:script>echo on:onjsdle:script>echo on:off </jsdle:script>
The
variable specified as ^SWITCH_VAR^ in the job maintains the value of
on because variables in this format are resolved when the job
stream is added to the plan and are not refreshed when the job is submitted to run. Instead,
the variable specified in the format, ${SWITCH_VAR}, which was previously
set to on is now updated with the new value in the variable table
off. Creating a variable definition using the Dynamic Workload Console
- Click HCL Workload Automation&→;Workload&→;Design&→;Create Workload Definitions
- Select an engine name and click Go
- Open in edit mode an existing variable table from the Quick Open pane, or create a new variable table as described in Variable table definition
- In the Properties - Variable Table panel, click the Variables tab and add new variable definitions by clicking the "+" (Add) icon and specifying variable names and values
For more information, see Customizing your workload using variable tables.