Jobs

The job is one of the basic objects of Entire Operations. Entire Operations regards a job as a user-defined task that is performed by JCL instructions and job IDs, scripts or files as supported by the operating system, Entire Operations subnetworks or dummy jobs, or Natural programs. For all types of jobs supported by Entire Operations, see Job Types described in the following section.

This document covers the following topics:

For detailed information on using and maintaining jobs, see the sections Job and Job Maintenance in the User's Guide.


Job Types

Entire Operations supports the following types of jobs:

  • Standard jobs of the operating system (z/OS, z/VSE, BS2000);

  • Started Tasks (z/OS);

  • Standard shell scripts of the UNIX operating system;

  • BAT files on Windows systems;

  • Other scripting environments on UNIX and Windows (e.g.: Perl, Windows Scripting Host);

  • Command-line oriented executables on UNIX and Windows;

  • FTP jobs;

  • SAP jobs;

  • Natural programs;

  • Data file generation;

  • Windows services;

For more information about job types, see the section Available Job Types in the User's Guide.

In addition, for non-CPU jobs there are:

  • Dummy jobs to create time windows for non-CPU jobs or Boolean connections for single conditions.

Job Attributes

Each job in the network is defined by a series of identifying attributes:

  • (logical) name

  • job type

  • node ID for job location

  • node ID for job execution

  • starting time

  • end-of-job information

  • user ID under which job is run

Such a job can be contained in several job networks.

Jobs in a Multi-Machine Environment

When Entire Operations is used in a Multi-Machine Environment, the location of a job (i.e. the location of its contents) and the location of its execution node can differ: at activation time Entire Operations reads the job information from the source node and executes it on the target node.

Jobs in a network can be interlinked by using Logical Conditions.

See also: z/OS: JES2 /*ROUTE Statement

Job Control Considerations

This section covers the following topics:

z/OS: JES2 /*ROUTE Statement

If a z/OS JES2 JCL contains a statement

/* ROUTE XEQ <target>

the job will be executed on the target machine.

As long as the SYSOUT will be passed back to the submission machine, the running job is not accessible. Entire Operations detects a rerouting, and behaves differently for such jobs.

For rerouted z/OS jobs, some features do not work, e.g.

  • Direct execution tracking.

  • Browsing of SYSOUT while the job is executing.

  • Cancelling

However, if the SYSOUT is available again, all end-of-job checking and end-of-job actions can be performed.

UNIX

Start of instruction setTo use the .profile file

Execution of UNIX shell scripts: To allow the usage of profiles in non-login scripts (as they are submitted by Entire Operations), the follow profile handling was added:

  1. During submission of a UNIX shell script, the Entire Operations Monitor checks whether the symbol ETC-PROFILE exists in the symbol table of the active job, or in another symbol table in the standard symbol search hierarchy, up to SYSDBA/A

    • If the symbol ETC-PROFILE is found, and if it contains "Y", the batch frame (*.BF) script will source /etc/profile and /etc/profile.local (only if they exist)

    • The user's script (*.B) will find the environment variables of the profile scripts being set.

  2. During submission of a UNIX shell script, the Entire Operations Monitor checks whether the symbol ENV exists in the symbol table of the active job, or in another symbol table in the standard symbol search hierarchy, up to SYSDBA/A.

    • If the symbol ENV is found, and if it is not empty, its content is assumed to be a startup script like $HOME/.profile.

    • If the startup script exists, it's name will be assigned to the environment variables ENV and BASH_ENV by the "batch frame" (*.BF) script.

    • If the user's script (*.B) is a Bourne shell, Borne again shell, or Korn shell script, the shell executes the content of the previously set ENV resp. BASH_ENV environment variable.

Note:
The user is responsible to make the used profile scripts proof against multiple execution, e.g. by using the PROFILEREAD variable like in Linux.