The objects that can be maintained in Entire Operations in order to process and control job networks are described in this section.
This document covers the following topics:
The following diagram shows all Entire Operations maintenance objects and indicates their relationship and dependencies and the conditions required to maintain and run a job network:
|
|
must be only one |
|
|
none or at most one |
|
|
must be at least one, can be more than one |
|
|
none or one or many |
|
|
direction indicator |
|
|
is sent to |
|
|
contains prompting for |
|
|
contains |
|
|
uses or can use |
|
|
contains messages for |
|
|
authorizes |
|
|
can choose |
|
|
lends properties to |
|
|
is composed of |
|
|
is based on |
|
|
is the basis of |
|
|
belongs to |
|
|
owns |
|
|
obtains parameters from |
|
|
contains values for |
|
|
schedules |
|
|
is scheduled on the basis of |
|
|
is executed as |
|
|
resides on |
|
|
is platform for |
|
|
runs on |
|
|
is preliminary condition for |
|
|
depends on or can depend on |
|
|
determines result of |
|
|
is checked for |
|
|
triggers |
|
|
is set according to |
|
|
is set or reset according to |
|
|
is performed according to |
|
|
sets |
|
|
A network master object can have several versions (see Object Versioning). |
|
|
A symbol table master object can have several versions (see Object Versioning). |
Note:
You can click on a symbol in the diagram above for more
information on the respective object.
Each Entire Operations user is assigned a user ID for the purpose of security, profiling, message switching and logging.
Each user ID is associated with a user profile which contains authorizations. A user profile can be modified by an authorized user (e.g. the system administrator).
This section covers the following topic:
User Maintenance - Administration documentation
Using Owners - User's Guide
Owners enhance security and ease of use by grouping user IDs and associating job networks to these owners.
The concept of owners 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.
A user can be authorized to use several owner names: switching owner names means selecting another group of job networks, which can then be maintained.
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. See also
Granting
Definition: Authorizing Other Users or Owners to Access a
Network in the User's Guide.
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 title of most system windows.
The following figure provides an example of the relationship between users, owners and job networks:
All three users may maintain networks belonging to owner Payroll, while User 3 is also authorized to access networks belonging to owner Finance.
In Entire Operations, a job network is a group of jobs, tasks, scripts or processes that may or may not be interrelated and which are scheduled for work according to a job network schedule table. Thus, a job network can represent any unit of business work in production work flow.
You can even integrate into these job networks manual tasks, which are to be performed at fixed times by data center personnel. The following figure illustrates an example of a job network for the automatic generation of pay slips and summary reports as it might be implemented in a payroll department:
In the normal case, a job network consists of a chain of jobs linked together by certain dependencies (e.g. in the simplest case: If Job 1 finishes OK, start Job 2). These dependencies are expressed by logical conditions.
A network is the smallest unit that can be activated automatically by Entire Operations. By using calendars, networks can automatically be scheduled for activation on workdays only. Apart from this, you can manually activate networks at any time.
Several active copies (or activations) of a network can work in parallel, since Entire Operations identifies each copy uniquely by its run number, which is automatically assigned to each network at activation time.
You can use a job to define subnetworks within a main network. This allows you to build nested networks.
This section covers the following topics:
Defining a Subnetwork - User's Guide
Network Maintenance - User's Guide
Defining a Network Schedule - User's Guide
Schedule Maintenance - User's Guide
Before Entire Operations can activate a job network, this job network must be defined as a network master to the master database. You can add a short description for easy identification when reviewing networks. You can specify default nodes for JCL and job submission on the network level. You can also specify a symbol table on the network level. Node and symbol table are then used as defaults for all jobs contained in the job network but can be overwritten for each job individually.
Scheduling a job network means defining dates and times at which it is to run. A job network is activated (copied into the active database) according to its scheduled starting time and additional schedule parameters defined for the network.
While processing a network, the Entire Operations Monitor checks whether all prerequisites for a job are fulfilled (time, resources, input conditions). According to the result it will automatically start the job and keep track of it.
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 section covers the following topics:
Job Maintenance - User's Guide
Scheduling a Job - User's Guide
Schedule Maintenance - User's Guide
A job is defined by (a logical) name, type and location (PDS member, Natural library, etc.) as a job master to the master database.
You can add, delete and modify jobs in the network. You can add a short description for easy identification when reviewing the jobs in the network. You can also specify, for example, a node and symbol table for job execution to override the defaults defined for the job network.
The activation of each job depends on the scheduling parameters defined for it. As in the case of job networks, you can define time frames.
For jobs, however, you can additionally specify whether a scheduled job that did not run (e.g. due to hardware problems) is to be rescheduled (i.e. the job is scheduled to run twice at the next scheduled time). You can also specify a number of days to determine how long a job can reside at most in the active queue before it is executed.
You can also specify an estimated job running time which the Entire Operations Monitor uses to calculate starting and end time for the job. This can prevent a job from running if a predefined deadline would be exceeded.
The job scheduling parameters also provide a facility to notify specified users if the start of job fails to meet the defined deadline starting time.
Entire Operations supports the following types of jobs:
Standard jobs of the operating system (z/OS, z/VSE and BS2000);
Started Tasks (z/OS);
Shell scripts of the UNIX operating system;
BAT files and PowerShell scripts 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;
Natural programs;
Data file generation;
Windows services;
In addition, for non-operating system jobs there are:
Dummy jobs to create time windows for non-operating system jobs or Boolean connections for single conditions.
Subnetwork jobs to define a subnetwork within a main network. This allows you to build nested networks.
For more information about job types, see the section Available Job Types in the User's Guide.
Each job in the network is defined by a series of identifying attributes:
(Logical) name;
Job type;
Node for JCL location;
Node for job execution;
Time frame;
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 the z/OS: JES2 /*ROUTE Statement described in the User's Guide.
A job needs job control language (JCL) instructions to perform a task. Exceptions are dummy jobs and subnetwork jobs that are used for special purposes within Entire Operations.
The required JCL is contained in the JCL member of a library/file of the operating system, or in a Natural object contained in a Natural library/system file.
This section covers the following topics:
Defining and Managing JCL for a Job - User's Guide
Dynamic JCL Generation (JCL Location MAC) - User's Guide
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 in the User's Guide). This is referred to as dynamic JCL generation and only applies to jobs with macro sources (JCL location MAC) in Entire Operations.
The use of logical conditions is the central concept of Entire Operations. Logical conditions are used to describe job or network dependencies. A logical condition can be set by any event that occurs during job processing. This event must occur before Entire Operations can proceed to the next step.
When a job network is activated, each logical condition is assigned a run number. This run number enables Entire Operations to distinguish between the same event that occurs during different network activations.
Logical conditions can be used in two different ways:
As input conditions;
As output conditions.
This section covers the following topics:
For more detailed information on conditions, see the sections Defining and Managing Job Conditions and Defining and Managing End-of-Job (EOJ) Checking and Actions in the User's Guide.
For information about prerequisite checking, see the section Prerequisite Check before Job Submission.
The following figure illustrates the concept of input and output conditions in relation to a job:
All input conditions must be fulfilled before a job can be submitted (prerequisite condition). You can define any number of input conditions for a job.
An output condition can be set or reset according to the result of predefined events (either automatically given by Entire Operations or user-defined). As part of End-of-Job analyses, Entire Operations checks for the occurrence of such events. Several output conditions can be set or reset for each event at the job or even job step level.
Defining and Managing Job Conditions - User's Guide
Jobs in a job network are linked by defining an output condition of one job as an input condition for the next job, as illustrated by the figure below:
A specified event occurred as a result of Job A. This sets the condition, signaling to Entire Operations that Job B can be started.
You can also link jobs together which belong to different job networks or which are executed on different computer nodes.
The following figure is an example of the job dependencies for the job network of a payroll department:
The following table gives an overview of the job dependencies (logical conditions) that link the jobs illustrated above:
| Job Number | Input Condition | Output Condition |
|---|---|---|
| JOB-1 | n/a | PRESENCE-OK |
| JOB-2 | n/a | SALARY-OK |
| JOB-3 | PRESENCE-OK | CHECK-OK |
| SALARY-OK | ||
| JOB-4 | CHECK-OK | UPDATE-OK |
| JOB-5 | UPDATE-OK | BONUS-OK |
| JOB-6 | UPDATE-OK | REPORT-OK |
| JOB-7 | UPDATE-OK | PAYMENT-OK |
| JOB-8 | REPORT-OK | NETWORK-COMPLETED |
| PAYMENT-OK |
For example, Entire Operations will not start JOB-7 (Generate payments) until the input condition UPDATE-OK is fulfilled (this condition is also defined as the output condition for JOB-4).
This job flow is completely independent of the operating system platforms on which the individual processing steps run.
End-of-Job checking refers to the process of how Entire Operations recognizes the job status on job completion.
This section covers the following topics:
Defining and Managing End-of-Job (EOJ) Checking and Actions - User's Guide
When the job has just completed, Entire Operations searches for the occurrence of user-defined events. Such an event can be any of the following:
A return code is received in a specific job step;
A return code is received in any job step;
A string is found in the job protocol or output;
A Natural user exit is executed which determines the End-of-Job status by returning a certain condition code. This routine can:
examine the job protocol or output itself,
read data produced by the job,
perform system functions,
send messages.
For each specified event, you can define how Entire Operations has to react. Such system action can consist of any of the following, for example:
Automatically set or reset the output conditions associated with this event (see the section Output Conditions);
Send a message (see Defining Notification Messages in the User's Guide) to a specific operating system user, the system console, an Entire Operations mailbox or an e-mail address;
Cancel or print job protocol and output;
Perform a recovery (if a job or job step failed);
Pass files to Entire Output Management (NOM) (see the User's Guide).
Depending on the operating system where the job was executed, Entire Operations performs some default checks to determine the job result. For z/OS systems, for example, system abends or JCL errors will automatically be detected. These default checks will be executed for each job, regardless of whether specific user-defined checks were requested for a job.
For detailed information, see the section Operating System Dependent Defaults for Event Checking in the User's Guide.
Within Entire Operations, mailboxes serve to send network- and job-related messages and requests to users and/or groups of users. These messages can be used to inform users about the current status of the job network or to request some data needed for further execution.
The messages and requests listed for a mailbox are generated by the Entire Operations Monitor as a result of either automatically generated processing information or user-written messages and requests defined for jobs. Requests can require user interaction to continue job processing, such as setting a condition or performing symbol prompting.
Using the concept of mailboxes:
tasks can be made dependent on logical conditions and can also set logical conditions;
mailboxes can be assigned to these logical conditions to specify who should be informed about them.
This section covers the following topic:
Working with Mailboxes - User's Guide
Mailbox Definition - Administration documentation
The concept of mailboxes allows you to integrate manual actions into the job network as illustrated in the following example of a mailbox for paper supply:
- Explanations:
The condition
Paper-OKis 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 following figure illustrates the concept of mailboxes when one or more users are linked to a mailbox using the example of the payroll department job network:
- Explanations:
User 1 (who could be in data collection) is notified that the condition PRESENCE-OK is not fulfilled.
He can then take the necessary steps by completing personnel attendance data and confirming this in his mailbox, when finished.
User 3 (who could be an assistant or backup of the personnel manager) is notified of any unfulfilled condition and can thus supervise the running of the whole job network. Users 3 and 4 are notified when the network has ended (NETWORK-COMPLETED) and the pay slips can be distributed.
Resources can reflect real resources or they can be fictitious. The existence of real resources can be determined using Entire System Server features. For example, you can examine the size of free space on any available disc, the presence of any cataloged data set or the actual number of running jobs.
Entire Operations resources are only meaningful within Entire Operations and are used to further regulate the job flow. They can be used to determine the job sequence within the job flow or prevent jobs from running in parallel if all other prerequisites (e.g. time windows or logical conditions) are fulfilled. For example, if a user defines a certain quantity of a resource as a prerequisite for a specific job, then this job will not run until this amount is available.
In our example of the payroll department job network (Job Network with Logical Conditions), we could prevent Job 6 (Generate employees reports) and Job 7 (Generate payments) from running in parallel by defining a resource (e.g. CPU time) with an initial quantity of 100, and defining this resource for each job with a required value of 60. The jobs will then run sequentially.
For detailed information, see Handling Prerequisite Resources for a Job in the User's Guide.
Calendars of any number can be defined to the system and easily modified online. They can apply to a dedicated owner or to the whole system.
The only purpose of having calendars in Entire Operations is to distinguish between workdays (working days) and holidays (non-working days). Entire Operations does not perform any activities on holidays. Entire Operations accounts for holidays by not activating a network if the scheduled date is marked in the calendar as a holiday.
You can determine whether a job network scheduled for execution on a holiday should be activated before or after the scheduled day or whether it should be cancelled.
On the other hand, if you want a job network to run, for example, each Friday, you do not need a calendar.
This section covers the following topics:
Calendar Maintenance - User's Guide
Calendars are referenced by schedule tables which are defined in the network maintenance facility. Calendars can belong to an owner or be used system-wide. In the calendar maintenance facility, you can add, delete or update a calendar (system-wide calendars can only be modified by the system administrator).
A calendar is defined by name and year. Defining new calendars or modifying existing ones consists of specifying or marking holidays (non-working days).
Schedules contain the planned execution dates of job networks. They can contain periodic and/or explicit schedule dates as indicated in the following graphic:
You can define an unlimited number of schedules, and one schedule can be referenced in different job networks.
If a schedule table is based on a predefined calendar, execution dates can be defined relative to holidays (for example: the last workday of a month).
Schedule Maintenance - User's Guide
Symbol tables are user-defined tables, each containing a list of symbol names together with their current value. These tables are used during dynamic JCL generation. The benefit of using a symbol table is that it must be created only once, but can be referenced in a huge number of jobs.
You can define any number of symbol tables and use them just by specifying their name in the definition of the appropriate job networks.
Symbols can be defined for prompting during or before job network activation.
Each network activation has its own active copy of the linked symbol table(s). This allows you to schedule networks with different parameter sets, even a long time in advance.
Any occurrence of a symbol name in the JCL or in a script is replaced by its current value from the symbol table. You can use two escape characters to determine whether this replacement should take place at JCL generation time or at job submission time.
There is also a large number of predefined symbols (see the User's Guide) available within Entire Operations.
Symbols are searched for in several tables (like in STEPLIBs) as described in Symbol Table Types and Symbol Search Order (User's Guide). Symbols can contain other symbols recursively; system variables can be used to construct symbol values.
A symbol table belongs to an owner. Any number of symbol tables can be associated with an owner. You can update all symbol tables of all owners for which you are authorized.
Symbols can be examined and modified by APIs (Application Programming Interfaces) from any Natural application. Scheduling such a program as part of an Entire Operations job network makes it possible to modify active symbol tables even during the execution of the job network.
Symbol Table and Symbol Maintenance - User's Guide
With Entire Operations you can use different versions of objects of type job network and symbol tables.
The versioning of job networks and symbol tables is optional.
For each job network and for each symbol table you can decide individually whether you like to use versions, or not.
You may use versioning:
to archive previous network versions, so that they can be activated manually any time later;
to archive previous symbol table versions;
to prepare new network versions or symbol table versions for future use;
to define which version is to be used for scheduled network activations.
For detailed information on object versioning, see Maintaining Job Network Versions and Versioning of Symbol Tables in the User's Guide.
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. More than one operating system server node can reside in one physical machine.
The machines identified by nodes 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:
Definition of Nodes - Administration documentation
