This section also introduces you to the Entire Operations components and facilities you can use to control and monitor the system.
In general, all components and facilities are available for all operating systems supported by Entire Operations. Exceptions and platform differences are described in this section, where relevant.
Before full control of batch processing can be passed to Entire Operations, certain objects must be defined to the system. This section gives a brief description of these objects and how Entire Operations uses them.
See also:
Performance Considerations in the Installation and Operations documentation
Concepts and Facilities documentation
Within Entire Operations, the term "operating system class" means one or more operating systems, which are usually handled in the same way.
| Operating System Class | Operating System |
|---|---|
| B | BS2000 |
| M | z/OS |
| V | z/VSE |
| X | All supported UNIX operating systems including AIX, HP-UX, Linux and Sun Solaris |
| W | All supported Windows operating systems |
In Entire Operations, a user ID can be used to enter the system. Entire Operations user IDs should, but need not be defined to the host TP monitor.
Several users can log on to Entire Operations with the same user ID and password at the same time. For reasons of data security and in order to trace data modifications, however, each user usually has a personal user ID and password.
Entire Operations user IDs are relevant to the following:
Entire Operations User Profiles
Each Entire Operations user ID can have individual access rights to
Entire Operations functionality and Entire Operations objects. For details, see
User
Definitions and Profile Settings in the
Administration documentation.
Mailboxes
A user ID can be associated with up to ten mailboxes through which
the user is notified of any pending logical conditions linked to those
mailboxes (see the section Mailboxes);
Logging
Entire Operations logs all activities and events occurring within the
system, including user activities.
A user ID always has a link to at least one owner (see the section Owner).
This document covers the following topics:
If you want to work with operating system objects (e.g. editing JCL), you must perform Entire System server logons to the nodes you want to work with. After such a logon, you have access the access rights of the operating system user ID you specified. See the section Logging on and off an Operating System Server Node.
For Entire Operations networks and jobs, you must define operating system user IDs specifically as JCL user IDs and submit (execution) user IDs. See also Defining Operating System Dependent JCL Specifications in the section Job Maintenance.
If you want to work with an operating system object and if you are not logged to the defined Entire System Server node, the node logon screen is presented automatically in many cases.
You may also perform an explicit node logon, by using the
LOGON
NODE direct command.
To view your current node logon status, use the direct command
STATUS
NODES.
In network and job definitions, it is possible to specify
a JCL user ID for the JCL node;
a submit (execution) user ID for the execution node.
Additionally, it is possible to specify a group (UNIX), respective a domain (Windows).
If no group is defined for an UNIX node, the user ID’s default group will be in effect.
If no domain is specified for a Windows node, the user ID is treated as a local user. If you enter the node’s host name in the domain (group) field, the user ID is treated as local user too.
If no operating system user ID definition is made for JCL node or execution node locally, Entire Operations determines an operating system user ID, depending on
For detailed information, see the relevant sections in the Administration documentation.
If an operating system user ID other than the user ID of the Entire
Operations Monitor (Submit Security User Type =
M/User ID of the Entire Operations Monitor) is to be used, a
search hierarchy for the operating system user ID is in effect. The fields
Monitor User ID and Submit Security User
Type are described in
Monitor
Defaults - General in the
Administration documentation.
The search order is:
The job’s (JCL or submit) user ID;
The network’s (JCL or submit) user ID;
The node’s default user ID (mainframe, UNIX and Windows);
The ID of the user who last modified the job.
This applies to the network master definition, job master definition and job active definition.
Symbol replacement is possible in the fields:
JCL User ID
JCL Group
Submit User ID
Submit Group
If the activation escape character is used, the replacement is performed at activation time. This is required for JCL user ID and group. If the submission escape character is used, the replacement is performed before job submission. Symbol replacement errors in one of these fields are treated as permanent errors.
Entire Operations provides ease of use and enhanced security through the concept of owners. This involves dividing job networks into groups by assigning them to an owner name. The system administrator assigns an owner name to a user ID in the User Maintenance facility (see User Maintenance in the section System Administrator Services of the Administration documentation). This owner name is automatically passed to the job network defined by the user.
An owner can thus represent a department or project, or a group of related job networks. Users belonging to a specific owner can perform functions only on those job networks associated with the same owner.
Note:
In special cases, a user can be authorized to access networks
belonging to other owners. The owner SYSDBA is authorized to access the
networks of all owners.
Any number of job networks can be associated with any one owner. A job network name is unique within the System only in combination with its owner name.
Access to most other Entire Operations objects is also owner-dependent. The owner name appears in the top line of most system screens and windows.
The figure below illustrates the links between users, owners and job networks:
In the Job Maintenance facility of Entire Operations, various job types can be defined.
All jobs are members of job networks and can be linked by logical conditions. Some differences arise in End-of-Job checking, depending on job type and operating system (see the section End-of-Job Checking and Actions). However, you can always define Job OK or Job not OK as a condition for subsequent system action.
For z/OS and z/VSE: An operating system job can consist of several steps. In these cases, Entire Operations can check the result of each job step as part of End-of-Job analyses and triggers system action accordingly.
A job is uniquely identified within a job network by its job name. The job name can, but need not be the same as the JOB or LOGON statement name (job name by which the operating system identifies the job). Before job submission, jobs can therefore only be identified by the name defined to Entire Operations. A job can only be accessed through Entire Operations by its Entire Operations name.
When defining a job, you must also specify:
JCL location (depending on job type);
JCL and execution nodes (if different from those, specified for the job network);
JCL and submit user IDs;
Scheduling parameters (optional, otherwise network default used);
End-of-Job checking and End-of-Job action specifications (see the section End-of-Job Checking and Actions for details).
For further information, see also Job Maintenance.
Note:
(z/OS only) We recommend that the JCL of one Entire Operations job
contain only one job statement. Entire Operations retains only the first
assigned job number of a submitted job.
A job network is a group of jobs that stand in defined relation to each other. This relation is composed of dependencies, which are expressed as logical conditions. In the simplest case, two jobs in a job network can be linked by the condition: If Job 1 finishes OK, start Job 2 (see Logical Conditions).
A job network is uniquely defined by its owner and network name. Each network is given a start and deadline time which determine when the network is to be activated. If your installation includes multi-CPU support, you can also specify a default node name for the jobs in the network. This node name can be overridden at the job level (see Operating System Server Nodes).
A user can only access a defined job network if his or her user ID is associated with the same owner as the network, unless he has special authorization to access other networks.
A job network and a single job are the units of work that can be activated by Entire Operations. When a job network is activated, it is automatically given a run number that uniquely identifies this network activation. This feature allows several copies of the same job network to run simultaneously.
A job network can be a subnetwork of another job network.
A job of the type NET
(Subnetwork) enables you to define a subnetwork within a
main network. This allows you to build nested networks. The subnetwork must
already exist when the definition is created. The same subnetwork can be
defined in different jobs of the main network. On activation, each active
subnetwork is assigned a unique run number. Subnetworks can in turn be invoked
within subnetworks. However, a subnetwork cannot invoke itself, because this
could cause an infinite recursion.
For detailed information, see Defining a Subnetwork in the section Job Maintenance.
This section covers the following topics:
Logical conditions are variables within Entire Operations and describe job dependencies. Condition names must be unique within a job network.
An active condition reflects the current value of the condition for a given job network activation. It can have the value true (the condition exists) or false (the condition does not exist). The run number assigned to the job network at activation is automatically passed to the conditions defined for the jobs in the network. An active condition is uniquely identified by owner, network, run number and condition name.
In Entire Operations, logical conditions are used in two roles:
As input conditions;
As output conditions.
These are described in more detail below.
Logical conditions can be global. You can have only one global condition per name and system. See also Global Conditions in the section Job Maintenance.
Input conditions are prerequisites for job submission. Entire Operations does not submit a job until all input conditions and other prerequisites are set (fulfilled). An input condition can be set by the occurrence of an event detected by Entire Operations or manually by the user from the Active Conditions screen in the Job Maintenance facility. It can also be set by a reply to a mailbox request.
If no input condition is defined for a job, Entire Operations assumes a virtual true input condition. This means that this job can be submitted immediately at the (earliest) starting time defined for it, unless the job has other prerequisites such as resources.
Jobs are linked by defining the output conditions of one job as the input conditions of the subsequent job. For more information, see Defining and Managing Job Input Conditions in the section Job Maintenance. A quick way to link two jobs is to use the connect function, in which Entire Operations provides a default condition as an output condition for one job and as input condition for another (see Connecting Jobs from the Same or Different Networks in the section Job Maintenance).
Input conditions can refer not only to the current run of a job network, but also to given time frames in the past or to previous runs.
You can also use an input condition to turn a job into a dummy job when it occurs. For further information on this topic, see Input Conditions and Job Execution as a Dummy Job.
Output conditions can be set or reset during End-of-Job checking of Entire Operations. For each job or job step (operating system job), you can specify any number of possible events. Each event can be associated with up to 20 output conditions. When any of these events occur, Entire Operations automatically sets the associated output conditions and starts those jobs which have these conditions as input conditions (see also End-of-Job Checking and Actions).
The figure below illustrates a simple example of two jobs linked by logical conditions:
To link the two jobs: an Output Condition of Job 1 is defined as an Input Condition for Job 2.
Each active job is checked for its prerequisites, before it can be submitted. Only, if all defined prerequisites are available at the same time, the job can be started. The prerequisite checking of an active job is repeated until all defined prerequisites are available, but only before its latest start time is reached.
The following prerequisites must be met before a job can start running:
The start and end times defined for a job or network must be reached,
The input conditions defined for the job must be fulfilled,
The resources defined for job usage must be available,
Operating-system specific objects defined for a job (for example, a BS2000 user switch) must be available, and
The execution node defined for the job or network must be available.
Entire Operations uses several procedures to reduce the effort involved for the prerequisite check. These procedures are transparent to the user. Nevertheless, they are explained in the following section.
The sort order of prerequisite checking is:
Earliest start time,
Owner, network, run, job.
The sort is only applied to jobs, which reside within the prerequisite check input queue at the same time.
Active jobs waiting for one or several input conditions, resources or for the availability of an operating system server (node) are placed into a particular queue, which removes them temporarily from the active check carried out by the Monitor.
Active jobs are woken up (released) from the passive wait:
During setup or deletion of active prerequisites at any location;
During setup or deletion of resources at any location;
After modification or deletion of definitions for input conditions and resources in active jobs;
During Monitor start;
During change of the day;
By explicit request; see Special Functions in the Administration documentation.
After a wake up, an active check of the prerequisites, resources and operating system server is carried out again. If the prerequisites required for job start are not met, then another passive wait can result out of this.
Note:
The main passive wait release routine does not re-activate the
waiting jobs at the same time. Instead, it performs the release in portions of
300 jobs. Between the portions, there is a wait of 30 seconds. This spreads the
Monitor and database activity for the prerequisite check of a large number of
jobs over a longer period of time.
The following graphic shows the course during passive wait for prerequisites:
|
|
A network has been activated and job processing is controlled by the Monitor. |
|
|
The prerequisites of a job are checked after
job activation.
If a prerequisite is not met (for example, the execution node defined for the job is not available), the prerequisite check stops at the position where it failed. |
|
|
The job is placed into an active wait state
waiting for the next check to meet the required prerequisite.
The next check continues at the position where the previous check failed. |
|
|
The Monitor determines how long to wait for the missing prerequisites before it places the job into a passive wait state. |
|
|
A trigger routine reactivates the job if the
criteria defined to reactivate the job are met (for example, the missing
execution node is available now), and forces the job back to active checking.
The check procedure (from active to passive wait and vice versa) can repeat several times. |
|
|
If all prerequisites are met, the job is submitted for execution. |
Note:
Each time the Monitor is started, all jobs in the passive wait
queue are reactivated for another prerequisite check.
A job cannot be placed into a passive wait state in the following cases:
Waiting for an input condition which depends upon the existence of a file;
Waiting for an input condition which depends upon the result of a user exit.
In these cases, Entire Operations cannot acknowledge on its own when such a job is to be placed again into the active wait. Therefore, in such a case, an active job is not placed into the passive wait.
Nevertheless, at least for part of the wait, a passive wait can also be carried out for these jobs, if, in parallel to the above mentioned cases, they are waiting for a normal prerequisite, which is set up as shortly as possible before job submission.
In other words: it is recommended to replace a wait for prerequisites with special dependencies by a wait for normal prerequisites.
If prerequisites and resources of an active job are actively checked, then the order of the job checks will be optimized dynamically.
For a follow-up check, the last unsuccessful check will be the starting point. This prevents successful checks from being redundantly repeated several times. It is guaranteed, however, that immediately before the job start release all input conditions and resources have been checked together at one point in time.
The following diagram shows the course of the Round-Robin Procedure for the check of prerequisites and resources:
In the terminology of Entire Operations, an event is the occurrence of a defined situation which is recognized during End-of-Job analysis. Entire Operations automatically triggers system action, depending on the occurrence of events during job processing (see the section End-of-Job Checking and Actions). Any number of events can be defined for a job.
Some examples of possible defined events are:
Exit code of a UNIX job equals 2;
STEP2 of JOB1 ends with a condition code greater than 8;
No job step ends with a condition code greater than 0;
A defined message appears in the job SYSOUT;
A database or file contains or does not contain certain expected data;
The result of a user exit (expressed by its return code).
A job variable contains certain expected data (BS2000).
End-of-Job actions refer to all actions performed after termination of a job. These actions can be performed automatically by Entire Operations or manually by the user.
End-of-Job checking and actions consists of two steps:
Analysis of job results (determination of End-of-Job status);
Triggering of appropriate system actions.
Entire Operations recognizes End-of-Job status by the occurrence of events predefined by the user. Such an event can be, for example, any of the events described in the previous section.
The internal result table used during the End-of-Job checking has space for 1200 entries per job.
If you do not specify any event, Entire Operations provides a default event expressed as Job OK or Job not OK, depending on whether a received condition code is greater or less than a default condition code, or, for BS2000, whether certain system messages are received.
For each of the user-specified or default events, you can define how Entire Operations is to act. Such an End-of-Job action can consist of any of the following:
Set output conditions to continue with job flow;
Send message to user or console with information about any abnormal event or pending condition;
Print or cancel job SYSOUT data;
Pass output files or SYSOUT to Entire Output Management;
Execute user exit;
Activate other job networks;
Perform recovery;
Set job variable (BS2000 only).
See also the section End-of-Job Checking and Actions for more information.
On z/OS: The job result check will be retried by the Monitor up to 10
times, when the message Job disappeared from Spool Queue
appears.
The wait interval between SYSOUT read attempts is constantly at least 30 seconds (not to be confused with the Monitor wait time, because it may be very short).
On BS2000: Entire Operations can only check job SYSOUT if it is
assigned to a file. JCL of jobs that are to run under Entire Operations control
must therefore not contain SYSOUT assignments to
*dummy,
primary or to a temporary file,
otherwise no End-of-Job checking is possible.
See also Defining Job SYSOUT Actions.
This section covers the following topics:
See also:
Handling Prerequisite Resources for a Job in the section Job Maintenance
Viewing and Modifying Resources Used by Active Jobs in the section Active Job Networks
Resources in the Concepts and Facilities documentation
Resources in the Administration documentation
Resources can be prerequisites for a job. Entire Operations does not submit a job until the amount of resource defined is available. You can thus use resources to further control the job flow when all input conditions for jobs that can run parallel are set. You do this by defining the priority with which resources are allocated to a job.
Resources can be
Quantitative or absolute;
Reusable or not reusable.
Some examples of resources are listed below:
| Resource | Type |
|---|---|
| Print forms | Quantitative, not reusable |
| Main storage | Quantitative, reusable |
| Line to a remote machine | Absolute |
| Availability of a device | Absolute |
Each resource must be defined in the System Administrator Services as a master resource, before it can be defined as a prerequisite for any job.
The current amount of a master resource can be determined by an exit, which will be invoked periodically by the Entire Operations Monitor. For a detailed discussion, see Resource Master Determination Exit.
Resources can reflect real system resources or they can be virtual. Entire Operations monitors resources as defined in the Network and Job Maintenance facility (see Handling Prerequisite Resources in the section Job Maintenance).
The following rules apply for the ordering of resource allocations:
If a resource is requested by the same owner, network, job, but different runs (at the same time), the active job with the lowest run number or earliest activation time will get the resource first.
If several different jobs of one active network or of several active networks wait for the same resource: The available quantity of the resource will be allocated to as many as possible jobs in parallel, but under the restriction of item 1.
If a resource waiter with a higher priority is found during a
prerequisite resource check, the message Res.
resource available, other jobs have
priority will be written to the log. It is followed by
Res. resource - waiting with higher
priority: and one or several lines with context information.
Usually a resource is allocated for the duration of a job execution. Before Entire Operations, resources could be allocated only in this way.
Starting with Entire Operations, it is possible to allocate resources for a longer period. This can be defined in the prerequisite resource definition for a job (deallocation mode).
The resource deallocation modes you can set are described in the section Job Maintenance.
Source deallocation will be forced if the resource allocation period is longer than retention period for active conditions.
The location and reason of resource releases is logged:
During network deactivation;
During job deactivation;
During forced freeing of a resource allocation;
During cleanup.
It is possible to inhibit a resource deallocation if a job ended
not ok. This can e.g. be used to keep a resource during a recovery
for an unsuccessful run. The additional rules apply here, too. This means that
such a resource will also be released automatically if the allocating job is
deactivated.
See the field Deallocate if Job not ok in the Prerequisite Resource Definition (Master) window described in Columns and Fields: Prerequisite Resource Definitions in the section Job Maintenance.
All current resource allocations can be inquired in usage lists. From these active resource usage lists it is possible to force the deallocation of a given resource allocation.
For further information, see Listing Jobs Currently Using a Resource in the section Resources in the Administration documentation.
Please use this feature with care. Be aware that one or several active jobs may be started immediately, which were way for this resource.
The available amount of a resource can be determined by the usage of an exit. A resource master determination exit (described in the Administration documentation) will be invoked by the Entire Operations Monitor before prerequisite resource checks.
Mailboxes are used for message sending to Entire Operations users. If a message requires a reply, it can be prompted in the mailbox window.
Any input condition can be assigned to a user interaction. You can send a mailbox request to notify a user to take appropriate steps and manually set the conditions necessary for a job to continue.
The concept of mailboxes thus allows you to integrate manual actions into the job network.
The following figure illustrates an example of a mailbox for paper supply:
The condition Paper-OK is defined as input condition for
Job 2.
On receiving the message Condition Paper-OK
pending, you can supply the required amount of paper and set the
condition manually, directly in the mailbox window at your terminal. Entire
Operations can then proceed with the next job (print report).
The mailbox SYSDBA, which is accessible for the owner SYSDBA, contains all messages for which no recipient was defined.
You can find a detailed description of all mailbox features in the section Working with Mailboxes.
Nodes are Entire System Servers and refer to machines on which requests to the operating system are executed. They are distinguished by numerical identifiers in the same way as database IDs distinguish between different Adabas databases. Within Entire Operations, each machine is assigned a node name. More than one operating system server node can reside in one physical machine.
The machines identified by node names can run different target operating systems. Entire Operations recognizes the operating system.
Communication paths between otherwise isolated nodes are provided by the Software AG products Entire Net-work and EntireX Broker, which allow a transparent connection of nodes, irrespective of how they are physically linked.
When defining a job network in Entire Operations, you can specify default nodes for the JCL and execution of all jobs in the network. These default nodes can be overridden for any job, so that different jobs within the same network can run on different machines.
The following example illustration shows how Entire Operations can support servers and nodes on different machines and operating systems:
For more information, see Definition of Nodes in the Administration documentation.
This section covers the following topics:
The master database stores all user, job network, job and scheduling definitions. It also contains all information pertaining to defined logical conditions, resources, calendars, and symbol tables. All information stored on the master database can be maintained online.
For further information, see Master Database in the Concepts and Facilities documentation.
When a job network is activated, it is copied to the active database. The active database can contain several copies of the same job network, each distinguished by its unique run number. All current information pertaining to condition status, job status, active JCL and symbols is contained in and can be modified on the active database.
The master and active databases are normally located within the same physical DB file.
For further information, see:
Active Database in the Concepts and Facilities documentation
Direct command SET
ACTIVE (sets the selection criteria for the active
database) in the Direct Commands documentation
Cleanup of the Active Database in the Administration documentation
Cleanup in Batch Mode in the section Special Monitor Features and Batch Jobs
This section covers the following topics:
The Entire Operations Monitor activates and processes job networks according to their scheduled dates and times. This includes the following functions:
Activation of scheduled job networks;
Check of prerequisites to job submission (input conditions and resources);
Job submission;
End-of-Job checking and actions;
Logging of all events.
In technical terms, there are two ways of running the Monitor: as one or several subtask(s) or as a batch task:
The Monitor can be run as one or several subtask(s) of an Entire System Server task in z/OS or z/VSE operating systems.
The JCL of the Entire System Server task (XCOM node) must be extended to meet the needs of the Monitor. The XCOM parameters must also be extended. The REGION assignment for the Entire System Server task must be large enough to contain the Monitor. For more details, see the section Installing Entire Operations on Mainframes in the Installation and Setup documentation.
The advantages of this method are:
all Entire System Server calls of the Monitor against its host node are handled locally, without any inter-PROCESS communication, and
Entire System Server and the Entire Operations Monitor share the same address space.
The Monitor can be run as its own batch task in z/OS or BS2000.
The Monitor can run as any normal batch job. The functions it provides in this mode are the same as when it runs as an Entire System Server subtask. However, as a batch task, the Monitor requires that the operating system server node must be active all the time it is active itself.
From an implementation point of view, the Entire Operations Monitor is a special user within Entire Operations. The difference is that the Monitor is not driven by any terminal input but by its own processing rules.
The system administrator can define a time interval between Monitor cycles. At the beginning of a cycle, the Monitor "wakes up" and checks the Entire Operations work queues, performing any necessary actions such as submitting jobs and End-of-Job analysis. The time between cycles depends on the number of jobs defined to the system and the average job run time. The shorter the wait time, the shorter is the interval between job termination and its End-of-Job analysis. The price for this is increased overhead due to Monitor reactivation.
The individual functions that the Entire Operations Monitor performs can be distributed to several subtasks. Subtasking allows processes to run in parallel and increases performance. Monitor functions can be distributed to subtasks under z/OS, z/VSE, BS2000 and UNIX. Under BS2000 and UNIX, Monitor subtasks are separate processes in the operating system.
For information on how the usual Monitor functions can be distributed, see Using the Monitor Task Profile in the section System Administrator Services of the Administration documentation.
If a job network with the name MON-START is defined under the owner SYSDBA, this network is executed exclusively at each Monitor startup. This is called the Monitor start network.
No other job network is started until the start network is terminated correctly.
The last job of the start network must not set any condition (but can reset conditions). During execution of the start network, the absolute condition SYSDBA/MON-START-RUNNING is set.
If any job of the start network ends not OK, this condition remains true
and blocks any other Monitor action. The condition can be reset manually to
free continuation of other processing. While the absolute condition is active,
the message Start Network still running appears in the
log and on the system console during each Monitor pass.
See also Monitor Start Network in the section Special Monitor Features and Batch Jobs.
This section covers the following topics:
Activating a job network or job means preparing it for execution. On activation, the following is performed:
The definitions of jobs, networks, logical conditions, symbol tables etc. are copied to the Entire Operations active database and assigned a unique run number;
If necessary, symbol prompting is requested (see also Symbol Prompting during Network or Job Activation). However, symbol prompting is not performed for any subnetworks.
The global activation exit user exit is invoked, if defined in the Entire Operations defaults;
The JCL defined for jobs within the network is copied to the Active JCL storage on the active database;
Variables (symbols) used in dynamically generated JCL are substituted by their current values. This does not apply to variables defined to be substituted at job submission time;
The JCL definitions of active job networks, respectively of active jobs, can differ from the JCL definitions in the master definition. To allow this, the corresponding symbol tables must contain certain reserved symbols on activation. See also Predefined Symbols in the section Symbol Table and Symbol Maintenance.
If you use pre-generated JCL, symbol replacement is performed at the time of JCL generation.
The Entire Operations Monitor recognizes the job network as active and checks time frames, input conditions and resources defined for the jobs. If all prerequisites for any jobs are fulfilled, these jobs are submitted.
During a network activation or single job activation, the list of the required (active) symbol tables (see the section Symbol Table and Symbol Maintenance) will be determined by Entire Operations. The result of the determination will be written to the Entire Operations log.
It may look like this:
List of active Symbol Tables created Determined Symbol Table Versions for 17.01.14 ... Ob Job St SymTab defined determined ... NV 00 N1649T00 (current) -> v002 ... JM J001 00 N1649T00 (unnamed) -> (unnamed) ... JM J003 ED N1649T00 (current) -> v002 ... JM J004 ED N1649T00 (nv) -> (unnamed) ... JM J005 ED N1649T00 (svn) -> v002 |
The column St contains the status of the symbol table to be activated.
ED means "evaluation duplicate". It will be
set if a previous determination (evaluation) resulted in the same symbol table
with the same version. In this case, the symbol table (version) will be
activated only once.
The determined symbol table versions (see the Concepts and Facilities documentation) will be used for the following symbol table activation.
In case of any determination error, the network activation of job activation will be aborted.
In this documentation and on the user interface, the terms activation and network start/job start are used.
Activation
denotes the process of creating an active copy of a network or job
definition.
Network start/job start
denotes the actual execution start time of the activated/active job
network or job.
Job networks are activated automatically in two steps:
At the beginning of a new day or during Monitor startup, all schedules are checked for job networks to be executed during that day. This process is called schedule extraction and the data extracted are called the activation trigger records.
The activation trigger records force job network activation a short time before the earliest start of the network. This time span can be defined in the Entire Operations defaults: see the Extraction of Schedules option described in Default Setting (2) in the Administration documentation.
Notes:
After the creation of an activation trigger record, active symbol tables are created for the specific network run. If there is at least one symbol marked as to be prompted within these active tables, a symbol prompting request is sent to the mailboxes of all users defined as message recipients for that network.
The network activation is kept in hold, until any user sees the request and enters or confirms the symbols to be prompted. For this reason, schedule extraction can be performed several days in advance. (See Global Schedule Extraction in the section Special Functions in the Administration documentation.)
It is also possible to activate a job network manually irrespective of any defined schedule. This may become necessary for a number of reasons, for example:
No schedule has been defined for the job network;
To override defined activation date and time;
The job network is not scheduled for the required date.
Job network or job activation can also be triggered by any event within Entire Operations, for example by the termination of another job network or by the Entire Operations Application Programming Interface (API); see also Accessing Entire Operations from other Applications. Like manual activation, this can be performed at any time.
Symbol prompting for active symbols is also performed, when a job or network is activated manually, if at least one symbol of a symbol table used by the job or network is appropriately marked.
If the calculated latest start is after the calculated deadline, the last start will be set 1 minute before the deadline.
If the (new) latest start is before the earliest start, the job activation will be aborted with an error message.
Entire Operations automatically assigns a run number to each active copy of a job network on the active database. This run number uniquely identifies the active copy of a job network and is automatically passed to its jobs, input conditions, etc.
The run number is assigned:
During the creation of an activation trigger record;
During a manual activation;
If a network is activated by an API routine.
Run numbers are in the range 1 to 99999 by default and are unique on network level. When the maximum run number has been reached, assignment again starts from 1.
The upper limit for run numbers can be modified in the Entire Operations defaults as described in Default Setting (2) in the Administration documentation.
The assignment of a run number to each activation of a job network allows multiple activations of a job network on the same date, and allows you to distinguish between multiple active copies of the same job network.
Note:
There is no guarantee that subsequent activations will have ascending
run numbers. They are as unpredictable as operating system job numbers. Entire
Operations retains the last run number, even for deleted job networks. If you
define a new job network of the same name, the new run numbers start from the
deleted network's last run number incremented by 1.
A schedule is a predefined time table according to which a job network is activated. Entire Operations monitors schedules to determine which job networks are to be activated.
You can define activation dates in a schedule as explicit dates and/or periodic dates (days of the week, days of the month or a combination of days and months).
Entire Operations can optionally account for holidays in a schedule. For example, if you schedule a job network to run on every first day of a month and the schedule table is based on a calendar in which Saturdays and Sundays are defined as non-working days, then Entire Operations does not start the job network if the first day of the month is a Saturday or Sunday. Activation can be postponed until the following working day (Monday). In other words, Entire Operations can automatically interpret the first day of a month as the first working day of a month.
A schedule can be based on a predefined calendar which distinguishes between working days and non-working days (see the section Calendars).
You can inspect the defined schedule in calendar format, irrespective of whether activation dates are defined as explicit or relative dates: Entire Operations automatically translates relative dates into explicit dates.
You can make the execution of single jobs in a network dependent on their position in the schedule (for example, first schedule day of the week) or in the calendar (for example, last workday of the year).
For more information, refer to:
Calendars can form the basis for schedule tables defined for jobs and job networks. An Entire Operations calendar distinguishes between working days and non-working days as defined by the user (weekends, national holidays, personal vacations).
Calendars can be modified to change, include or delete non-working days. Modifications to calendars can affect the associated job network schedule(s).
Calendars are identified by owner, name and year, and can belong to an owner or be used system-wide. You can specify a system calendar or a calendar belonging to your owner for a schedule table, but you can only modify calendars belonging to your owner. System calendars can be modified by authorized users only.
Any number of calendars can be defined to Entire Operations. For further details, see the section Calendar Maintenance.
A symbol table contains a list of symbols (variables) that can be used for string substitution during JCL generation.
You can substitute symbols when activating a job network or job, that is, when the active JCL is loaded to the active database. You can also substitute symbols when submitting a job.
For detailed information on using symbol tables and symbols, see the section Symbol Table and Symbol Maintenance.
This section covers the following topics:
Defining and Managing JCL for a Job in the section Job Maintenance
Job control is used in Entire Operations as follows:
Master Job Control
The JCL in its original format on the original storage medium. The
usual JCL storage locations of the various operating systems are supported. The
source texts for dynamic JCL
generation are also considered master job control.
Active Job Control
The actual JCL submitted to the operating system for execution. It is
produced from the master JCL when the job or network is activated. The symbols
are replaced with values from the active symbol table. If it is dynamic JCL,
the generation is performed at this time. The active JCL is stored in the
active Entire Operations database.
Pregenerated Active Job Control
For reasons of performance, it might be necessary to generate active
JCL in advance. See also Pregenerating Active
JCL in the section Job Maintenance.
The JCL must be pregenerated again when:
The definition of the master JCL storage has been modified;
The master JCL has been edited;
The corresponding symbol table has been modified.
Job control can be edited with the Software AG Editor.
For detailed information on editing JCL, see Editing JCL and Natural Sources in the section Job Maintenance.
When Entire Operations activates a job network, the JCL of the jobs in
the network is copied onto the active database. Entire Operations provides a
facility which allows you to use variables in the original JCL and which can
create parts of the JCL depending on program logic. Variables are substituted
by their current values either at activation time or at job submission time
(see Symbol
Replacement). This is referred to as dynamic JCL
generation and only applies to jobs with JCL location MAC (macro
Natural source) in Entire Operations.
Dynamically generated JCL is useful if you wish the JCL to contain a
step only under certain circumstances, for example, if the current date is
YYYYMMDD, include job step X.
For information on defining dynamic JCL for jobs, see Defining and Managing JCL for a Job in the section Job Maintenance.
For information on editing macro JCL, see Editing Master JCL and Natural Sources and Editing Macro Sources for Dynamic JCL Generation in the section Job Maintenance.
The Entire Operations library contains some routines that can be invoked
from any other Natural application to provide access to Entire Operations
internal data. These routines are called the Application Programming Interfaces
(APIs) and can be invoked simply with a Natural CALLNAT
statement.
The Application Programming Interface provides the following features:
Dynamic connection to the Entire Operations data file;
Access to conditions;
Access to symbols;
Writing to the Entire Operations log.
The Application Programming Interface can be used for a number of purposes within and outside Entire Operations. Among them are:
Dynamic modification of symbol tables during the execution of a job network;
Modification of conditions from Natural programs;
Exchanging information between Entire Operations and any other online or batch application;
Setting input conditions for job networks from online applications;
Inquiring the status of job networks from applications;
Setting Entire Operations symbols from external tables;
Inquiring Entire Operations symbols for use in external applications.
For more details, see the section API Routines.
The execution of a dummy job means that the job is running without job
control and without its own action within Entire Operations. Dummy jobs can
have an expected run time, which they will be waiting in the system. Dummy jobs
will always terminate with the state o.k..
For detailed information on dummy jobs, see Using a Dummy Job in the section Job Maintenance.
The Entire Operations Logging facility records every event and user action during job network processing. This information is available online. From the system log, you can select more detailed logs for individual jobs if logging at job level is specified at job definition time.
The default system log displays information about activities in the system as a whole such as user actions, date and time of events and messages about events. If more information is available for any item on the system log, it is preceded by an asterisk (*). Log information at the job level can be any of the following:
JCL log
Displays the JCL of a specific job run;
SYSOUT log
Displays the SYSOUT of a specific job run;
System message log
Displays all operating system messages about jobs. The system log
displays the first of these messages. You can select a job from the system log
to display all system messages for that job.
A selection window in the Logging facility asks you to select the default log according to owner, network, job and run number.
For more information, see the section Log Information.
Entire Operations can send messages to various locations. This is triggered by system-detected events and user-defined events.
Many message destination types can be defined. Among them is the sending of e-mail on mainframes and e-mail on UNIX and Windows systems.
You can select the global events, which trigger message sending by Entire Operations.
Optionally, you can use a global exit for message sending. This exit detects all messages that must be sent for various reasons by the Entire Operations Monitor. The exit can store the message content in files and forward the message to other applications, etc.
See also Message Sending in the section End-of-Job Checking and Actions.
Entire Operations displays status or error messages at the following locations:
| Location | Description |
|---|---|
| On the current screen | If Entire Operations is used online.
In many cases, additional information is written to the Entire Operations log. Subsequent to more complex errors it is recommended to have a look there. For more information, see Log Information. |
| Message column of the Active Jobs or All Active Jobs screen | Contains the last status message or error message for the active
job.
For more information, see the Message column described in Listing All Active Jobs for All Active Networks. |
| Entire Operations System Log screen | Contains all status messages and error messages.
If database problems prevent you from writing to the log file, then the messages will be written to the SYSOUT of the Monitor tasks. For more information, see Log Information. |
| Monitor Task(s) SYSOUT | Contains mainly start and end messages of the Monitor tasks.
In this case, some other important events are also logged in addition. |
| Console | On mainframes, weighty messages of the Monitor tasks are written
to the system console.
In most cases, they are to be answered by the operator. An example of this is the non-availability of the database, while the Entire Operations Monitor is running. |
In Entire Operations, the languages English and German are available. The specified language controls the display in the following locations:
All application screens and windows including status and error text messages;
All online help texts including field-specific information;
The Entire Operations log file.
Note:
Entire Operations log messages are saved independent of the language.
You can view them in English or German.
This section describes the locations where you can change the user language depending on your authorizations:
Enter either of the following Entire Operations direct commands and press ENTER:
SET LANGUAGE 1
(for English)
SET LANGUAGE 2
(for German)
See also the SET direct
command in the Direct Commands documentation.
The language settings are kept for the duration of the Entire Operations session.
As an administrator, you can specify the language in the following locations:
On the Default Setting (1) screen of the System Administrator Services function.
In a user profile on the User Definition and Profile screen.
See the relevant sections in the Administration documentation.
The Natural ULANG profile parameter controls the language
used by the Entire Operations Monitor such as the SYSOUT of the Monitor tasks
and the Console output.
You can specify ULANG dynamically at the start of a
Natural session or, if authorized, statically in the Natural
parameter module/file.
ULANG is described in the Parameter
Reference of the Natural documentation.
The Reports function helps you overview your job network environment to define objects, monitor the system and plan workloads.
All report types available are described in the section Reporting.
The Cross References function is used to generate reports that contain cross references to individual objects.
All types of cross references available are described in the section Cross References.
Entire Operations provides a version of the Software AG Editor especially adapted to the Entire Operations environment.
You can use the editor to perform the following:
Create or edit JCL for jobs. Existing JCL can be edited, even if it was written outside of Entire Operations using other editors;
Create or edit JCL for jobs with JCL location MAC
(macro);
Write Natural programs to run as jobs in job networks or be executed as user exits;
Write and browse text descriptions at the network, job, and event level (online documentation);
Display JCL, job SYSOUT and listings in browse mode (no editing possible);
Display the Entire Operations system log.
See also Editing Master JCL and Natural Sources in the section Job Maintenance.
This section covers the following topics:
The operative data of Entire Operations must be removed again from the active database after a certain time. Part of this process is the removal of work files as well, which Entire Operations has created in the file system for job control purposes.
The retention periods for active objects can be defined (see Administration) documentation.
The cleanup may be defined to be carried out automatically every day. If no time is defined for the cleanup, then it will be started at 00:00. A time for the daily cleanup start can be defined. For a more detailed description, see Administration documentation.
The cleanup of the active database can also be started manually any time (see Administration documentation).
Furthermore, it is possible to run the cleanup of the active database in a Natural batch job (see Cleanup in Batch Mode) exterior to the Entire Operations Monitor. The cleanup in batch mode can be executed with the Monitor running or shut down.
Please note that the cleanup of the active database depending upon the data quantity to be processed affects the system. It is recommended to schedule the cleanup for silent times.
Cleanup runs can also be performed several times a day. This makes it possible to reduce the volumes to be processed per run.
Entire Operations creates files in the operating system under BS2000, UNIX and Windows. Among other things, they contain the job SYSOUT or the JCL to be executed.
During the deactivation of active jobs, which have run in one of these operating systems, the assigned work files are deleted as well.
For BS2000, the names of these work files might also have been generated with a name exit, which is used for work file deletion, too.
All definitions are created in the Entire Operations Defaults. They are described in the Administration documentation.
