Using variables in HCL Workload Automation jobs

This section explains how to add variables to jobs you plan to run with HCL Workload Automation.

When importing jobs from HCL Workload Automation, you can add variables to obtain higher flexibility for your job.

The variables are assigned a value when you submit the job in HCL Workload Automation. Built-in variables are available by default and are listed in Built-in HCL Workload Automation variables. You can optionally add custom variables in a variable table and use them in your job definitions. For more information about variable tables, see Variable table definition.

Table 1. Built-in HCL Workload Automation variables
Built-in variables	Description
tws.host.workstation	Name of the host workstation
tws.job.date	Date of the submitted job.
tws.job.fqname	Fully qualified name of the job (UNISON_JOB)
tws.job.ia	Input arrival time of the job
tws.job.interactive	Job is interactive. Values can be `true` or `false`. Applies only to backward-compatible jobs.
tws.job.logon	Credentials of the user who runs the job (LOGIN). Applies only to backward-compatible jobs.
tws.job.name	Name of the submitted job
this.name	The integration type of the job (for example, executable). Note that this variable returns theintegration type, not the name of the job.
job.<JOB_NAME>.name	The integration type of the specifically referenced job (for example, executable).
tws.job.num	UNISON_JOBNUM
tws.job.priority	Priority of the submitted job
tws.job.promoted	Job is promoted. Values can be `YES` or `No`. For more information about promotion for dynamic jobs, see the section about promoting jobs scheduled on dynamic pools in HCL Workload Automation: User's Guide and Reference.
tws.job.recnum	Record number of the job.
tws.job.resourcesForPromoted	Quantity of the required logical resources assigned on a dynamic pool to a promoted job. Values can be `1` if the job is promoted or `10` if the job is not promoted. For more information about promotion for dynamic jobs, see the section about promoting jobs scheduled on dynamic pools in HCL Workload Automation: User's Guide and Reference.
tws.job.taskstring	Task string of the submitted job. Applies only to backward-compatible jobs.
tws.job.workstation	Name of the workstation on which the job is defined
tws.jobstream.id	ID of the job stream that includes the job (UNISON_SCHED_ID)
tws.jobstream.name	Name of the job stream that includes the job (UNISON_SCHED)
tws.jobstream.workstation	Name of the workstation on which the job stream that includes the job is defined
tws.master.workstation	Name of the master domain manager (UNISON_MASTER)
tws.plan.date	Start date of the production plan (UNISON_SCHED_DATE)
tws.plan.date.epoch	Start date of the production plan, in epoch format (UNISON_SCHED_EPOCH)
tws.plan.runnumber	Run number of the production plan (UNISON_RUN)

The following example illustrates a JSDL file with several of the supported HCL Workload Automation variables defined:

…<jsdl:jobDefinition xmlns:jsdl="http://www.abc.com/xmlns/prod/scheduling/1.0/jsdl" xmlns:jsdle="http://www.abc.com/xmlns/prod/scheduling/1.0/jsdle" description="This jobs prints UNISON Variables received from TWS in standard OutPut " name="sampleUNISON_Variables">
  <jsdl:annotation>This jobs prints UNISON Variables received from TWS in standard OutPut </jsdl:annotation>
  <jsdl:variables>
    <jsdl:stringVariable name="tws.jobstream.name">none</jsdl:stringVariable>
    <jsdl:stringVariable name="tws.job.fqname">none</jsdl:stringVariable>
    <jsdl:stringVariable name="tws.master.workstation">none</jsdl:stringVariable>
    <jsdl:stringVariable name="tws.plan.runnumber">none</jsdl:stringVariable>
    <jsdl:stringVariable name="tws.plan.date">none</jsdl:stringVariable>
    <jsdl:stringVariable name="tws.plan.date.epoch">none</jsdl:stringVariable>
    <jsdl:stringVariable name="tws.job.logon">none</jsdl:stringVariable>
  </jsdl:variables>
  <jsdl:application name="executable">
    <jsdle:executable output="${tws.plan.runnumber}">
      <jsdle:environment>
        <jsdle:variable name="UNISON_SCHED">${tws.jobstream.name}</jsdle:variable>
        <jsdle:variable name="UNISON_JOB">${tws.job.fqname}</jsdle:variable>
        <jsdle:variable name="UNISON_MASTER">${tws.master.workstation}</jsdle:variable>
        <jsdle:variable name="UNISON_RUN">${tws.plan.runnumber}</jsdle:variable>
        <jsdle:variable name="UNISON_SCHED_DATE">${tws.plan.date}</jsdle:variable>
        <jsdle:variable name="UNISON_SCHED_EPOCH">${tws.plan.date.epoch}</jsdle:variable>
        <jsdle:variable name="LOGIN">${tws.job.logon}</jsdle:variable>
      </jsdle:environment>
…

The following example illustrates a job definition where variables are used to return both the name of the job and the plug-in type. For a job named TEST2 of type executable, the variables in the script are resolved as follows:

${tws.job.name} resolves to TEST2
${this.name} resolves to executable
${job.TEST2.name} resolves to executable

**$JOBS
WA_AGT#TEST2
 TASK
    <?xml version="1.0" encoding="UTF-8"?>
<jsdl:jobDefinition xmlns:jsdl="http://www.ibm.com/xmlns/prod/scheduling/1.0/jsdl" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:jsdle="http://www.ibm.com/xmlns/prod/scheduling/1.0/jsdle" 
xs:text="resolveVariableTable" name="executable">
    <jsdl:application name="executable">
        <jsdle:executable interactive="false">
            <jsdle:script>echo ${tws.job.name}
echo ${this.name}
echo ${job.TEST2.name}</jsdle:script>
        </jsdle:executable>
    </jsdl:application>
</jsdl:jobDefinition>
 RECOVERY STOP**