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.
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.
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.
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
This section covers the following topics:
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.
To 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:
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.
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.