Job statements and computer workstation operations

For jobs on z/OS® systems, store job statements for submitted jobs in the partitioned data sets that are allocated to the ddname EQQJBLIB. HCL Workload Automation for Z associates an operation with a member of one of these libraries, using the JOB NAME field of the OPERATIONS panel, shown in EQQAMOSL - Operations . That is, the job statements for a job or started task are stored in the member identified by the JOB NAME field. The rest of this section addresses the details of jobs on z/OS® systems.

HCL Workload Automation for Z submits the job statements if the operation is a job, or starts it as a procedure if the operation is a started task. So the job name of each job or started task operation must be unique to ensure that the correct job is picked up. Each time an operation is run, its job statements are picked up from EQQJBLIB, and are then stored in the job repository (a cycle of VSAM data sets with the ddname EQQJSnDS). The job statements remain there until the successful completion of the next occurrence of the application, and are then deleted. So the job repository should contain the job statements for the most recent completed run of any application in the current plan. HCL Workload Automation for Z always uses the job from the repository for reruns; this job is modified by the variable substitution and recovery functions. The original job, in EQQJBLIB, is always used for the first run of operations in an occurrence.

Variable substitution can be automatically invoked at job or started-task submission time, if you require. Alternatively, operators can be prompted for the values of variables before submission. See Job tailoring for more details.

Note:

HCL Workload Automation for Z checks the JCL for a valid job card if you specify JOBCHECK(YES) on the JTOPTS initialization statement. This applies only to jobs destined for z/OS®. If you specify JOBCHECK(SAME), it also checks that the job name is the same as the operation name.
It is not recommended that you have several jobs in the same member. If you do this, put the job that matches the operation (member) name last, or HCL Workload Automation for Z cannot track the job. You must not specify JOBCHECK(SAME). This applies only to jobs destined for z/OS®.
Do not use JCL that has been packed by ISPF in EQQJBLIB, because HCL Workload Automation for Z does not use ISPF routines to read it.
Do not include JCL with TYPRUN=SCAN in EQQJBLIB. HCL Workload Automation for Z does not track these jobs. To test JCL, do this outside HCL Workload Automation for Z, or add TYPRUN=SCAN using the MCP panel and type the SUBMIT command; then remove TYPRUN=SCAN or cancel the edit. This applies only to jobs destined for z/OS®.

If you use HCL Workload Automation for Z to submit jobs to non-z/OS operating systems, you need not store the JCL equivalent information in the EQQJBLIB. The operation-initiation exit, EQQUX009, which handles submission for operations at workstations that specify a user-defined destination ID, can be used to locate job statements from another file, or you can request the receiving operating environment to locate them. If the job statements are in EQQJBLIB, you can use the job tailoring and automatic recovery functions for these operations.

Note: Started task operations on workstations that specify a user-defined destination ID will be treated in the same manner as normal computer operations on user-defined destinations. That is, all job-statement information is passed to the operation-initiation exit, EQQUX009. You decide how the exit chooses to handle the information.