HCL Workload Automation, Version 9.4

< Previous

Dynamic job scheduling - A procedure to optimize writing job definitions that simulate the use of templates

This scenario shows how you can set up JSDL job definition templates that you can reuse for several job definitions. In this way you can optimize the number of steps required to submit jobs to dynamic workload broker. Taking this concept a little further, you can set up a different JSDL template for every class of job that you want to submit. For background information, see Using JSDL job definition templates in Scheduling workload dynamically.

Scenario goal

Typically, to run a job using dynamic scheduling, you write two definitions for the job: the definition for the database (that you write with composer or enter in the Dynamic Workload Console), and one definition stored in the Job Repository of dynamic workload broker (for which you use the Job Brokering Definition Console). The first definition specifies the type of job, the task string or the name of the executable, the name of the workstation where the job is to run (which for dynamic scheduling must be the workload broker workstation), scheduling dates, and recovery options. The second definition specifies the task string or the name of the executable, the types and quantities of resources needed to run the job, and optimization and scheduling details. There must be a 1 to 1 match between the two definitions. This means that you are duplicating work for every job that you want to submit by using dynamic workload broker.

You can avoid part of this work by following a number of steps to write a single JSDL definition file in the Job Brokering Definition Console that can be referenced by several job definitions. You can then use this file as a template to which you can link all the job definitions that match the required resources, and optimization and scheduling preferences specified in the template.


This section lists the user roles needed to run the scenario:
dynamic workload broker Developer
Defines the jobs using the Job Brokering Definition Console
dynamic workload broker Operator
Monitors and controls the jobs that have been submitted.
HCL Workload Automation Job Scheduler
Manages the workload by submitting and monitoring jobs.

Software requirements

The following software must be installed and configured, before running this scenario:
  • HCL Workload Automation with the dynamic workload broker feature enabled
  • Optionally, the Dynamic Workload Console.

Running the Scenario

To complete the scenario, perform the following steps:


  1. In the Job Brokering Definition Console, create a JSDL document and give it a name. In the Application page, after setting the Type to Executable, specify the following variable name in the Script field of the executable: ${tws.job.taskstring}. Fill in the data in the remaining pages, specifying the required resources, and the optimization and scheduling details. Save the document in the database. This is your template.
  2. With composer or with the Dynamic Workload Console define a workstation of type extended agent hosted by the workload broker workstation.
    If you need background information about extended agents, see the HCL Workload Automation: User's Guide and Reference. To create the template, you only need to know the following facts about an extended agent:
    • It is a logical definition that must be hosted by a physical workstation. For JSDL templates, the physical workstation must always be the workload broker workstation. The workload broker workstation is automatically installed when you install HCL Workload Automation with dynamic scheduling capabilities. This workstation can host as many extended agents as you need.
    • It requires an access method. An access method can be a complex program, but in this case it is only a statement that references the name of the JSDL document that is your template.
  3. Using composer or the Dynamic Workload Console write the job definitions that you want to match with the new template. To link these job definitions with your template, write the name of the extended agent as the workstation where the jobs are to run.
  4. Add the extended agent to the plan as you do for any other workstation. The workload broker workstation has the task of managing the lifecycle of the extended agent, notifying the master domain manager that it is up and running.

Expected Results

When jobs are run on the extended agent, they are routed to the workload broker workstation, which handles them differently from other jobs. Instead of searching for the name of the JSDL definition in the task string of the job, the workload broker workstation:
  1. Gets the name of the target JSDL from the access method, and passes the task string as a value for variable ${tws.job.taskstring}.
  2. Replaces the task string value in the script element of the target JSDL, and is used as a command string to run on the target agent that is dynamically selected by the dynamic workload broker.

    The JSDL definition invoked by the workload broker workstation works as a sort of template that you can use to run different task strings defined in different HCL Workload Automation jobs: the same JSDL document is reused for multiple jobs.

Sample Configuration files

You want to use dynamic workload broker to run three jobs that share the same resource requirements and optimization and scheduling preferences. You want to use a JSDL template to minimize the required number of definitions. The jobs are named SUBMIT_JOBXA1, SUBMIT_JOBXA2, and SUBMIT_JOBXA3. The following definitions achieve this:
  • The definition of the workload broker workstation. It is named DGCENTER_DWB and it is of type BROKER. There can be only one workload broker workstation running at a time in an HCL Workload Automation network (this applies also to the dynamic workload broker active instance).
      OS OTHER
      ENGINEADDR 31111
  • The definition of extended agent DGCENTER_DWBXA. The extended agent must:
    • Be hosted by the workload broker workstation (DGCENTER_DWB in this example).
    • Include the access method. While normally the ACCESS keyword is followed by the name of the program that implements the specific access method, for JSDL templates it needs only to define the name of the JSDL document that you use as the template - that must be available in a local directory in the workstation where you run the Job Brokering Definition Console - and whatever other parameters you want to use. These items must be enclosed between double quotes.

      This requires that you created the JSDL document you will be using as a template (named SJT in this example), defining the required resources, candidate hosts, and scheduling and optimization preferences, and specifying ${tws.job.taskstring} in the Script field of the executable.

      OS OTHER
      FOR MAESTRO HOST DGCENTER_DWB ACCESS "/jsdl/SJT -var target=D:\vmware,RES=RES1"
        TYPE X-AGENT
  • The job definitions in HCL Workload Automation.
    • The definition of job SUBMIT_JOBXA1:
       SCRIPTNAME "C:\Utils\Jobs\javacount_on.bat"
       STREAMLOGON Administrator
       DESCRIPTION "Counts files in APPMX directory."
    • The definition of job SUBMIT_JOBXA2:
       SCRIPTNAME "D:\Callcenter\Tasks\sortccalls.bat"
       STREAMLOGON Administrator
       DESCRIPTION "Sorts calls by customer."
    • The definition of job SUBMIT_JOBXA3:
       SCRIPTNAME "C:\Sales\Tools\runstats.bat"
       STREAMLOGON Administrator
       DESCRIPTION "Calculations on totalled business."
    Because the jobs are defined to run on extended agent DGCENTER_DWBXA, hosted by the workload broker workstation and matched with the SJT JSDL definition, the process:
    1. Submits the jobs via dynamic workload broker
    2. Uses the specifications of the SJT JSDL definition
    3. Replaces variable ${tws.job.taskstring} with the SCRIPTNAME of each job when the job is submitted.
< Previous