HCL Workload Automation, Version 9.4

Customizing jobs and job streams based on why they are scheduled to run

This scenario shows how to customize jobs and job streams based on why they are scheduled to run, for example to create a job that runs different commands for different users, referencing different variable tables at job stream level.

By having the ability to manage different tables of variables, you no longer need to create two different job definitions to run the same workload in different environments. Instead, you define a single job that can be used both in the test and in the production phase, using variables in the name of the file the job runs (scriptname job attribute) and in the name of the user under which the job runs (streamlogon job attribute). The variable tables are referenced in the job streams containing the job. Using variable tables you reduce the number of scheduling objects required to implement the desired workload saving therefore time and money.

You can find more information on this subject in the User's Guide and Reference.

Scenario goal

After an acquisition, a company needs to integrate the acquired company applications to its existing business environment. Before running them in the production phase, the company decides to try a test application that runs the new company application. After a month of testing, the application of the acquired company will run in the production environment with the production user.

Roles and skills

This section lists the users involved in the scenario, the related roles, and the required skill level:

HCL Workload Automation Job Scheduler: Manages Tivoli Workload Scheduler workload. Required skills include Tivoli Workload Scheduler knowledge.

System requirements

Install the following software before starting the scenario:

HCL Workload Automation version 8.5
Dynamic Workload Console version 8.5

Setting up the environment

Complete the following tasks before running the scenario:

Install and configure HCL Workload Automation version 8.5
Install and configure Dynamic Workload Console version 8.5

Running the Scenario

To complete the scenario, perform the following steps:

Procedure

Define the TABLE_TEST and the TABLE_PROD variable tables as follows:

VARTABLE TABLE_TEST
  MEMBERS
  USER_LOGON "test"
  PATH_SCRIPT "/usr/test"
END

VARTABLE TABLE_PROD
  MEMBERS
  USER_LOGON "mdm_85"
  PATH_SCRIPT "/export/home/mdm_85/TWS"
END

Define the following job:

JOB_APP_01
 SCRIPTNAME ^PATH_SCRIPT/applicationscript.sh"
 STREAMLOGON "^USER_LOGON^"

Define the following job streams, specifying the same name but different validity intervals:

SCHEDULE JS_APP_01
  VARTABLE TABLE_TEST
  ON RUNCYCLE RULE1 "FREQ=DAILY;" 
  :
  JOB_APP_01
END
 
SCHEDULE JS_APP_01
   VALIDFROM 05/19/2008  
   VARTABLE TABLE_PROD
   ON RUNCYCLE RULE2 "FREQ=DAILY;" 
  :
  JOB_APP_01
END

Generate a daily plan that ends on 05/18/2008, that is, the last day of the test phase.
When you complete the test phase, extend the plan by one day.

Expected results

After you perform Step 4, the JS_APP_01 job stream will be included into the plan generated, so that the JOB_APP_01 test job is included in the plan and you can verify that the job is correctly scheduled and will run the test application.

After you perform Step 5, the JS_APP_01 job stream is included into the plan running the JOB_APP_01 that uses as streamlogon and scriptname the values to run the acquired company application in the production environment, without having to modify the scheduling objects.

You can achieve the same result by using a single job stream in which you define two run cycles with different validity intervals, each run cycle referencing a different variable tables. The job stream has the following syntax:

SCHEDULE JS_APP_01
   ON RUNCYCLE RULE1 VALIDTO 05/18/2008 VARTABLE TABLE_TEST "FREQ=DAILY;"
   ON RUNCYCLE RULE2 VALIDFROM 05/19/2008 VARTABLE TABLE_PROD "FREQ=DAILY;"
   :
   JOB_APP_001
END

< Previous