Objective
Job B has two predecessors: job A and a data set trigger. If the data set trigger completes before job A, job B should run. If job A completes before the data set trigger, job B and the data set trigger job should both be forced complete.
Solution
This solution uses an Alert to check the status of the data set trigger when job A completes.
The dependencies look like this:
Take the following steps:
1. Set up an Application such that an Alert runs when job A ends. For example: APPL CYBER
JCLLIB 'CYBER.JCLLIB' JOB A
RUN ANY RELEASE B
NOTIFY JOBEND ALERT(CHCK) ENDJOB
DSTRIG WAIT4DS
DSNAME 'CYBER.THAT.DATASET' ANYCLOSE RUN ANY RELEASE B ENDJOB JOB B RUN ANY ENDJOB CHECK.STATUS A WAIT4DS B
2. Set up an Alert that invokes the following ESP Procedure: IF MNJOB EQ 'A' AND MNMXCMPC EQ 0 THEN DO REXXON
J=JOBONCSF('WAIT4DS','X') DO I = 1 TO J
IF XAPPL.I = 'CYBER' & XCOMPLETE.I = 0 THEN DO "ESP AJ B COMPLETE APPL(CYBER.%ESPAPGEN)"
"ESP AJ WAIT4DS COMPLETE APPL(CYBER.%ESPAPGEN)" END
END REXXOFF ENDDO
Explanation
The NOTIFY statement in the Application specifies that an Alert Event is triggered when job A ends. The Procedure invoked by this Alert Event uses the JOBONCSF function to check if the WAIT4DS job is complete.
If WAIT4DS is not complete, then job A has completed first, and two AJ commands force jobs B and WAIT4DS complete. Otherwise, WAIT4DS has completed before job A, and job B will then run.
ESP-5.5-EC-01 67
Scheduling a job based on a data set, time, and weekdays
Objective
A job waits for a data set to be created. This data set is normally created once or twice per week. However, the job should only run between 22:30 and 23:30 on weekdays, regardless of when the data set is created.
Also, the job should never run more than once per day. If the job has already run in the 22:30 to 23:30 time window, then the next instance of the job should wait until the same time period on the next weekday.
Solution
The solution involves the use of a resource to control when the job runs.
1. Define a renewable resource. In this example, the resource is called CYBERDSN. 2. Set up an Application that submits the job.
• Use WAIT on the APPL statement.
• Use RUN ANYDAY as the run frequency for the job as the Application should build regardless of when the data set is created.
• Assign 1 unit of the CYBERDSN resource to the job.
• Set up the job to release a link that sets the availability of the CYBERDSN resource to 0.
For example: APPL CYBER WAIT
JCLLIB 'CYBER.JCLLIB' JOB A RESOURCE (1,CYBERDSN) RUN ANYDAY RELEASE CYBERDSN.OFF ENDJOB
JOB CYBERDSN.OFF LINK PROCESS RUN ANYDAY
ESPNOMSG RESDEF CYBERDSN SET AVAIL(0) ENDJOB
3. Set up a data set-triggered Event to wait for the data set and invoke the Application. For example:
EVENT ID(PROD.CYBER) SYSTEM(ESPM) REPLACE INVOKE 'PROD.PROCLIB(CYBER)'
DSTRIG CYBER.DATASET.G- ENDDEF
4. Set up Events to turn on the resource (in other words, set the Avail count to 1) at 22:30 weekdays, and turn off the resource (in other words, set the Avail count to 0) at 23:30 weekdays. For example:
EVENT ID(PROD.CYBERDSN_ON) SYSTEM(ESPM) REPLACE SCHEDULE 22.30 WEEKDAYS
VS 'F ESP,RESDEF CYBERDSN SET AVAIL(1)' ENDDEF
EVENT ID(PROD.CYBERDSN_OFF) SYSTEM(ESPM) REPLACE SCHEDULE 23.30 WEEKDAYS
VS 'F ESP,RESDEF CYBERDSN SET AVAIL(0)' ENDDEF
Explanation
Two Events and a link control the availability of the resource:
• At 22:30 on weekdays, an Event is scheduled that issues the RESDEF command to make the resource available.
• At 23:30 on weekdays, an Event is scheduled that issues the RESDEF command to make the resource unavailable.
• After the job completes successfully, a link issues the RESDEF command to make the resource unavailable.
This ensures the job only runs between 22:30 and 23:30 on weekdays. Also, once the job runs, the link sets the resource to 0. This ensures the job will run only once a day. If another generation of the Application has been created when one generation completes, then the job waits for the resource to be available the next weekday.
ESP-5.5-EC-01 69
Using the Application name in the script path
Objective
The path to a number of UNIX scripts needs to include the name of the Application in lowercase.
For example:
• /export/home/payroll/batch, for the Payroll Application. • /export/home/billing/batch, for the Billing Application.
Solution
Use the following code, either for the Application or for specific jobs within the Application. You can have different Applications invoke this code or imbed the code in your Application definition. The code converts the Application name to lower case using REXX. REXXON APP = CLANGVAR('%ESPAPPL') APP=TRANSLATE(APP,'abcdefghijklmnopqrstuvwxyz',- 'ABCDEFGHIJKLMNOPQRSTUVWXYZ') "APPL='"APP"'" REXXOFF
For the location of the script, use %appl (or %APPL) in the path. For example: APPL ABCD UNIX_JOB MYJOB AGENT AGENT SCRIPTNAME /export/home/jsmith/%appl/sleep60 RUN DAILY ENDJOB Explanation
ESPAPPL is a built-in variable representing the Application name but it resolves to an uppercase name (for example, PAYROLL). While you can hardcode the Application name in lowercase, a generic routine that converts the name allows you to simplify maintenance should the name of the Application change. Or, if the name of the Application is dynamically generated, this solution converts that name.
This solution uses the REXX TRANSLATE function to convert the value of the ESPAPPL variable to a lowercase variable. Each uppercase letter is mapped to the corresponding lowercase letter. The result is assigned to a REXX variable called APP, which is then assigned to an ESP Workload Manager variable called APPL. You can use the APPL variable in the path to your scripts.