Home
HCL Workload Automation for Z
Welcome to the HCL Workload Automation for Z documentation, where you can find information about how to install, maintain, and use the product.
Scheduling End-to-end with z-centric Capabilities
Defining and managing jobs
Defining a job in the JOBLIB data set
You define the jobs to be run on HCL Workload Automation Agent workstations in a job definition member of the JOBLIB data set. In the JOBLIB member, you can either define the job contents or invoke a script or an executable that is stored locally on the HCL Workload Automation Agent workstation.
Syntax diagram for Java job type

HCL Workload Automation for Z
Welcome to the HCL Workload Automation for Z documentation, where you can find information about how to install, maintain, and use the product.
- Program Directory
- Dynamic Workload Console Readmes
  For the latest information about a Dynamic Workload Console fix pack, see the appropriate Readme File.
- Planning and Installation
- Customization and Tuning
- Managing the Workload
  You can plan when and how your workload runs and manage it as part of a plan.
- Scheduling End-to-end with z-centric Capabilities
  - About this publication
  - Configuring
  - Customizing the HTTP connections
    The communication between the HCL Workload Automation Agents and the HCL Workload Automation for Z controller is direct, through the HTTP or HTTPS protocol.
  - Defining user IDs and passwords with the USRREC statement
    Use the USRREC initialization statement to define the passwords for the users who need to schedule jobs to run on Windows™ workstations. You do not need to do this if you run native job types on non-Windows workstations.
  - Defining variables and passwords for local resolution
  - Defining and managing HCL Workload Automation Agent workstations in the database
    After defining the destinations of your HCL Workload Automation Agents, you need to define the HCL Workload Automation Agents as HCL Workload Automation for Z computer automatic workstations.
  - Defining and managing dynamic workstations
    When you add dynamic capabilities to your environment, you can schedule your workload dynamically.
  - Setting the security features
  - Defining and managing jobs
    - Defining jobs from the Dynamic Workload Console
      How to define a new job definition using the Dynamic Workload Console.
    - Defining a job in the JOBLIB data set
      You define the jobs to be run on HCL Workload Automation Agent workstations in a job definition member of the JOBLIB data set. In the JOBLIB member, you can either define the job contents or invoke a script or an executable that is stored locally on the HCL Workload Automation Agent workstation.
    - Using variable substitution
      The variable substitution mechanism that is used in HCL Workload Automation for Z native job types works the same way when scheduling jobs on HCL Workload Automation Agents. The variable substitution mechanism changes when you define job types with advanced options, such as Java™ jobs that run a Java class, or file transfer jobs that transfer files to and from a server, to name a few. These types of jobs are created and edited using the Dynamic Workload Console.
    - Defining file dependencies to check for file changes
    - Checking for file changes with filemonitor
    - Promoting critical jobs
      An overview of the mechanism that is behind the promotion of critical jobs, or of their predecessors, running on HCL Workload Automation Agents, including pools and dynamic pools.
    - Killing operations
  - Administering IBM i dynamic environment
    On overview on how to administer the HCL Workload Automation IBM i dynamic environment.
  - Monitoring and recovering jobs
  - Running a script when a job completes
  - Viewing the job logs from the host
    An overview on how to view or retrieve the job logs issued in the z-centric environment and how to attach a header with job run information on top of each log.
  - Troubleshooting
    Troubleshooting agent problems
  - Configuring to schedule J2EE jobs
  - Security order of precedence used for the execution of J2EE tasks
  - Configure to schedule job types with advanced options
  - Managing return codes
  - Collecting job metrics
- Quick Reference
- Diagnosis Guide and Reference
- Workload Automation Programming Language for z/OS User's Guide and Reference
- Driving HCL Workload Automation for Z

Syntax diagram for Java job type

Purpose

If you set JOBTYPE to (/java), you can run an existing Java class:

This section provides detailed information about the syntax diagram for the Java job type. The following syntax rules apply:

Use the UNIX format for the value of the JARPATH keyword.

Format

Parameters

CLASSNAME(java class name)

The name of the Java class to run. This keyword is required.

JARPATH(path name)

The path to the jar file.

JAVAPARMid(Java parameter name=value)

The Java parameter used by the Java class. You can define multiple parameters in the same job by specifying a series of JAVAPARMid keywords, where id is a unique numeric value, including null and zero. For example, you can define JAVAPARM1, JAVAPARM2, and so on.

Use the following format, which is case sensitive:

JAVAPARMid(Java parameter name=value)

Where:

Java parameter name: The name of the Java parameter.
value: The value associated with the Java parameter.

JOBTYPE(/xajob/access method name|/j2ee/jms|/web service|/file transfer|/database|/java)

To run a Java job, specify /java. For information about the other types of job, see the specific section for each job type.

/java: Set this value to submit a Java job. Ensure that you have list permissions for the folder specified in the jarPath property.

Examples

The following is an example of a JOBREC statement to run a class with name mypackage.base:

//JOBREC                         
	JOBTYPE(/java)                   
	CLASSNAME(mypackage.base)   
	JAVAPARM1(name=backup)             
	JARPATH(c:/jarPath2)             
//END JOBREC