OS390 JOBS

This subtype of the JOBS object defines z/OS390-specific processing steps to be carried out in a target system. Like all other job objects (JOBS), z/OS390 jobs can run independently or they can be added to a group (JOBG) or to a workflow.

The page contains the platform-specific execution parameters:

Validation Checks

The zOS/390 agent comes with various built-in checks that are carried out before submitting jobs to the JES in cases where they would not run anyway. If a job is blocked due to one of these checks it assumes the status 1683: Waiting for remote resource. A message is displayed in the Remote Status column on the Tasks window that explains the reason. Additionally, the blocking reason is logged in the job report (LOG).

Whether the agent carries out the checks or not is defined in the agent's INI file.

• Duplicate job check

  Before submitting a job to the JES the agent checks whether a job with the same name is already running. If it finds one, the job is not submitted.

  This is useful, for example, if you want to start multiple z/OS jobs that have the same z/OS name but different names in the Automic Web Interface. These jobs can be started in the Automic Web Interface but they would cause a queue in z/OS. This check avoids such situations.

  This check considers all the jobs in the same agent. Jobs submitted by other agents are not considered.

• Scheduling environment check

  For example, let's assume that you want to prevent a job from being submitted to JES if the scheduling environment defined in it is not available in any of the systems to which it may be submitted.

• Initiator check

  Let's suppose that you want to prevent the z/OS agent from starting additional jobs if all z/OS initiators are busy. Since the WLM in z/OS can adjust the number of available initiators, the agent must check the number of available initiators to be able to determine the maximum number of jobs that can be started at a certain point in time.

These checks provide several advantages:

• Jobs that cannot run at the moment do not use up the JES queue.
• Blocked jobs are marked as such in the Tasks window and information on the reason why this happened is also provided.
• Jobs in state 1683: Waiting for remote resource do not occupy abstract resources (WORKLOAD_MAX_JOB) within the Automation Engine.
• The runtime computation for temporarily blocked jobs is more accurate as the waiting time does not count as runtime.

These checks do not guarantee that every job that is submitted to JES, and is therefore Active, will run immediately. This is due to:

1. The nature of the checks
   • If the initiator check is only done at SYSPLEX level jobs may be submitted even if no single system has free resources.
   • The duplicate job check doesn't take jobs into account which were submitted by other agents, processes or users.
2. Timing issues

   It may happen that a resource becomes unavailable in the short time span between resource check and the submission of the job.

3. Job routing

   The resource checks do not take into account whether jobs will be routed to certain systems (due to SYSTEM/SYSAFF parameters) after submission. For example, the agent may find that the required scheduling environment is available on system A and submit the job, but due to the SYSAFF parameter the job is routed to system B where the scheduling environment is not available.

On the other hand, the default job class is inquired by the agent only once at start-up, either from JES or from the "defaultJobclass" parameter in the INI file. This means that if the default job class is changed while the agent is running, the scheduling environment and initiator checks will not work correctly for jobs without specified job class. In this case, the agent has to be restarted for the checks to work properly again.

Parameters Section

Field	Description
Type	Automation Engine (AE) - the job JCL is stored in the Pre-Process and/or Process page OS/390 JCL - the job JCL is available on z/OS If you select this option, the OS/390 File Name input field is displayed (see below). JCL incl. OS/390 job card The complete JCL including the job card is used from the dataset that has been specified in the OS/390 File Name input field. No runtime options are available as the definitions made in the job card apply. When generating a job, the JCL from the Pre-Process page is added before the first step. The script must be empty.
Job Name	The dataset that contains the JCL here. The job card is generated from the host attributes defined here. The Pre-Process JCL is added before the first step. The script must be empty. The job card defined in this Job object will be then inserted, whether the JCL contains a job card or not.
Program Name	The programmer's name - it identifies the job owner or its group (optional). The name is recorded in the job's job card. It can contain up to 20 characters.
Job Class	The specification of the job class in which the job should run (optional).
Account	Accounting information about the job. It can contain up to 40 characters.
Priority	The priority with which the job should be executed. It is a value between 1 and 15, where 1 is the highest and 15 the lowest priority. The priority does not affect the processing order of tasks, it only serves to define their starting order. The task with the higher priority is started first. For tasks with the same priority, the Fist In/First Out (FIFO) principle applies.
MSGCLASS	The assignment of the job log's message class (optional).
MSGLEVEL	The trace option for the job log (optional). Possibly a numerical value for command and message separated by a comma. Allowed formats: "Command,Message", ",Message" or "Command" Allowed values for outputting commands: "0" - Outputs exclusively commands "1" - All job commands, JES2 or JES3 control commands, procedure commands and all IEF653I messages "2" - All job commands (JCL) and the JES2 or JES3 control commands Allowed values for outputting messages: "0" - Only JCL messages. In the case of abortions also JES control commands and operator messages. For SMS errors also the corresponding messages. "1" - All JCL, JES, operator and SMS messages.
Notify	The specification of a notification on z/OS. It can contain up to 17 characters.
Scheduling Environment	The name of the Workload Manager (WLM) scheduling environment to associate with this job. A scheduling environment is a list of resources and their required settings. By associating a scheduling environment name with a job, you ensure that the job will be scheduled for execution only on a system that satisfies those resource state requirements.
Job Parameters
OS/390 File Name	The name of the dataset or member which contains: the JCL of the job (Option "JCL from z/OS") or the JCL and the job card of the job (Option "JCL incl. job card from z/OS"). For example: SYSS.AWA.JCL.JOB1 or SYSS.AWA.JCLLIB(UC4JOB1) Jobs can also derive from the source administration system Librarian. The following syntax applies: *LIBRARIAN(Dataset, Member). A maximum of 225 characters is allowed. Dataset name and member name must be put in single quotation marks as, otherwise, the agent will put the name of the user under which it runs in front. For example, in the following example IBMUSER.SYSS.AWA.JCL.JOB1 the agent ignores the first file line if type "z/OS JCL" is selected because it expects the job card in it.
Return Code	This setting is relevant if the job end should be monitored via SMF Records. The return codes of the job STEPS are collected in this case. Select Highest to use the highest return code when the job ends. Latest to consider only the return code which has occurred last. The administrator can specify whether SMF Records should be used for monitoring job ends. The relevant parameter is SMFJob= in the INI file of the Event Monitor and the variable UC_EX_JOB_MD=UC4START in the INI file of the agent.

Job Report Section

The following table describes the available options:

Field	Description
Store to	Database: As soon as the job has been processed, the process log available on the target system is stored in the database. File: The process log is stored as a file on the target system. You can select one option or both of them simultaneously.
Generate	Define when the operating system process log is written. Always: The process log is always written. On error only: The process log is written only when an error occurs, for example, when the job is canceled or aborted.
Job Log Complexity	Allowed values: Agent default configuration The job log complexity depends on the configuration made in the INI file of the agent (the completeJobout= parameter ). Store JES statistics and job output The JES statistics and job output are stored in the job log. Store only JES statistics JESMSGLG, JESJCL and JESYSMSG are included.
Delete Job Log	Agent Default Configuration Whether the job log is deleted depends on the configuration made in the INI file of the agent (the jobPurge= parameter). Delete after reading The job log is deleted after it has been read by the agent. Do not purge The job log remains in the JES spool.
Print Release	Agent Default Configuration Whether the job log is deleted depends on the configuration made in the INI file of the agent (the relMsgClass= parameter) Release after reading The job log is deleted after it has been read by the agent. Do not release The job log remains in the JES spool.
Obtain Message Classes	Message classes which should be read and routed. Specify one or several message classes. Examples: "A", "ABC", "X1". Any order is possible. The following values are also allowed: *DEFAULT and *ALL. DEFAULT The message classes which should be read depend on the configuration made in the INI file of the agent (the getMsgClass= parameter). If this setting is used, *DEFAULT must also be specified in the Route Message Classes to field. ALL All classes are read.
Route Message Classes to	Message classes that should be routed. After it has been transferred to the Automation Engine, the job log can be routed to the specified message classes (e.g. for an Output Management System). Enter either one or the number of message classes specified in Obtain Message Classes. The order is significant. For example: The following message classes are read "ABC" and routed "DEF". Class "A" is routed to class "D", "B" to "E" and "C" to "F". Another example: The following message classes are read: "ABC" and routed: "D". Class "A", "B" and "C" are routed to class "D". The following values can be used instead of message classes: DEFAULT The message classes which should be routed depend on the configuration made in the INI file of the agent (routeMsgClass= parameter). This setting must be specified if *DEFAULT has also been specified in the Obtain Message Classes field. NO No routing is made.

The list below tries to depict a possible road-map to define and work with Job objects and provides short descriptions of the actions you can take, additional information that can help you understand how they work and links to topics that further describe them:

1. Define the job general settings, which include the following:

   • The basics, on the General Page.
   • If required, apply a Sync object to the job; You do so on the Sync Page.
   • On the Runtime Page specify the job runtime settings.
   • Fine-tune access rights at object level on the Authorization Page.
   • Specify the object Attributes on the Attributes Pages of Executable Objects.
   • Register the output files that will be produced when processing them on the Output Page.
   • To be able to carry out searches in those output files and, if required, perform follow-up actions, specify these settings on the Output-Scan Page.
   • You may want to use variables or prompts. You do so on the Variables & Prompts Pages.
   • You may want to define the settings to backup and restore a job task when included in a workflow. This is useful to recover the last successful status in case of failed processes. You do this on the Rollback Page.
   • The Version Management Page lists all the versions of an object and allows you to restore it to an older version in case of a misconfiguration.
   • Enter information on the job you are defining on the Documentation Page.

2. Job objects (JOBS) have three pages on which you enter the scripts to be processed. They provide a number of convenience functions to help you with your work. If you enter scripts on all of them, they are processed in the following order:

   1. Pre-Process Page
   2. Process Pages
   3. Post-Process Page
   4. Child Post-Process (SAP and PeopleSoft only), see Child Post-Process Page.
3. You can easily reuse code using Include Object (JOBI), which saves time and helps you keep your scripts consistent.

4. Execute the job.

   There are multiple ways to do this that can be grouped as follows:

   • By a parent task.

     This is the case of jobs that are included in a parent object (for example a Workflow or a Group). When defining them, take into account that their activation time can be different from their start time; the latter usually depends on the parent object.

     See Superordinate Tasks (Parents).

   • Stand alone

     This is the case when the job is not part of a parent object or, even if it is, you execute it independently of its parent. You have three possibilities:

     • Executing Immediately
     • Executing Objects Once
     • Executing Objects Recursively

   When executable objects are processed, they go through the following four stages: 1. Activation, 2. Generation, 3. Processing and 4. Completion. Take a look at these topics to understand what happens with every processing stage.

5. When processing jobs, the Automation Engine generates output files and reports that guarantee traceability and auditability. Have a look at the following topics to learn more about this:

   • Registered Job Output
   • Job Reports
   • External (Directory) Reports
6. In the Process Monitoring perspective a number of functions are available, depending on the status of the job. See Working with Tasks.