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.
Roles
- 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:
Procedure
Expected Results
- Gets the name of the target JSDL from the access method, and passes the task string as a value for variable ${tws.job.taskstring}.
- 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
- 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).
CPUNAME DGCENTER_DWB OS OTHER NODE DGCENTER TCPADDR 41111 ENGINEADDR 31111 DOMAIN MASTERDM FOR MAESTRO TYPE BROKER AUTOLINK ON BEHINDFIREWALL OFF FULLSTATUS OFF END
- 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.
CPUNAME DGCENTER_DWBXA OS OTHER NODE DGCENTER TCPADDR 41111 FOR MAESTRO HOST DGCENTER_DWB ACCESS "/jsdl/SJT -var target=D:\vmware,RES=RES1" TYPE X-AGENT AUTOLINK OFF BEHINDFIREWALL OFF FULLSTATUS OFF END
- The job definitions in HCL Workload Automation.
- The definition of job
SUBMIT_JOBXA1:
DGCENTER_DWBXA#SUBMIT_JOBXA1 SCRIPTNAME "C:\Utils\Jobs\javacount_on.bat" STREAMLOGON Administrator DESCRIPTION "Counts files in APPMX directory." TASKTYPE WINDOWS RECOVERY RERUN
- The definition of job
SUBMIT_JOBXA2:
DGCENTER_DWBXA#SUBMIT_JOBXA2 SCRIPTNAME "D:\Callcenter\Tasks\sortccalls.bat" STREAMLOGON Administrator DESCRIPTION "Sorts calls by customer." TASKTYPE WINDOWS RECOVERY RERUN
- The definition of job
SUBMIT_JOBXA3:
DGCENTER_DWBXA#SUBMIT_JOBXA3 SCRIPTNAME "C:\Sales\Tools\runstats.bat" STREAMLOGON Administrator DESCRIPTION "Calculations on totalled business." TASKTYPE WINDOWS RECOVERY RERUN
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:- Submits the jobs via dynamic workload broker
- Uses the specifications of the SJT JSDL definition
- Replaces variable ${tws.job.taskstring} with the SCRIPTNAME of each job when the job is submitted.
- The definition of job
SUBMIT_JOBXA1: