Performing SRSTAT actions with LISTSTAT

As well as setting return codes, the POLICY statement can also perform SRSTAT actions based on the object status.

The complete syntax of the action to perform is as follows:

[rc/][[+|-|!]special-resource[/subsys]]

The plus sign (+), minus sign (–), or exclamation mark (!) used as prefix for special resources indicates whether to set the availability to YES (+), NO (–) or RESET (!). If neither the plus sign (+), minus sign (–), or exclamation mark (!) is specified, YES is assumed.

To direct the SRSTAT event to a tracker or controller different from the value specified in the SUBSYS= symbolic in combination with any setting of OPTIONS TRACKERS, you can append the subsystem to the end of the special resource name using the slash (/).

If a return code is not specified in front of a special resource name, RC=0 is assumed.

Note:
  • Special Resource names containing the slash (/) or the parenthesis cannot be used with this command.
  • If the special resource name begins with the plus sign (+) or minus sign (–), you must specify an additional plus sign or minus sign to explicitly set the availability.
In the following example, the job looks for operation 10 of an application called DAILYPLANNING that runs at 12:00 on the same input arrival date as the application running this Workload Automation Programming Language job.
  • It ends with RC=0 if the operation is complete.
  • It ends with RC=2 if the operation is not found in the current plan.
  • It ends with RC=8 and generate an SRSTAT event to set resource MY.SR.TRIGGER to available, which will be sent to SUBSYS(WSIT).
//RUNWAPL EXEC EQQYXJPX, 
//         SUBSYS=WSIC 
//SYSIN    DD * 
VARSUB SCAN
LISTSTAT CPOP ADID(DAILYPLANNING) OPNO(10) IA(!OYMD1.1200) 
         POLICY(C=0,?=2,W=8/MY.SR.TRIGGER/WSIT)
In the following example, the job looks for MYJOB10 and MYJOB20 of an application called MYJOBS that arrives at 23:00 the day before input arrival date as the application running this Workload Automation Programming Language job.
  • The command ends always with RC=0.
  • If MYJOB10 is in error it sets resource JOB.FAIL.MYJOB10 to available.
  • If MYJOB10 is waiting it sets resource JOB.WAIT.MYJOB10 to available.
  • If MYJOB20 is in error it sets resource JOB.FAIL.MYJOB20 to available.
  • If MYJOB20 is waiting it sets resource JOB.WAIT.MYJOB20 to available.
  • OPTIONS TRACKERS is used to determine where to send the event. Ordinarily this would be specified in your site options member.
//RUNWAPL EXEC EQQYXJPX, 
//         SUBSYS=WSIC 
//SYSIN    DD * 
OPTIONS TRACKERS(WSIC.*.WSIT)
VARSUB SCAN
VARDATE YESTERDAY BASE(!OYMD1.) OFFSET(-1)
LISTSTAT CPOP ADID(MYJOBS) JOBNAME(MYJOB10) IA(!YESTERDAY.2300) 
         POLICY(E=JOB.FAIL.MYJOB10,W=JOB.WAIT.MYJOB10,0) 
LISTSTAT CPOP ADID(MYJOBS) JOBNAME(MYJOB20) IA(!YESTERDAY.2300) 
         POLICY(E=JOB.FAIL.MYJOB20,W=JOB.WAIT.MYJOB20,0)

These special resources could be used to trigger different escalation or notification applications, therefore a failed job could use a Special Resource ETT rule with JOB.FAIL.* to trigger an application to indicate in Problem Management records that the job was still in a failed state during the night's processing. In the same way, using a JOB.WAIT.* trigger you could run a job to automatically send an email to support staff notifying them of the delay.

If you set //*%OPC SETVAR TJOB=SUBSTR(&OETEVNM,10,8) in the triggered application, you can obtain the job name, that was the reason for triggering the event, for use in that notification or escalation process.