Performance Considerations

#### Search Results

Search

# Performance Considerations

The Entire Operations system is based on Adabas, Natural and the Entire System Server. Therefore, the following performance considerations can be dedicated to these components or to Entire Operations itself.

This document covers the following topics:

- Entire System Server

- Natural

- Adabas

- Entire Operations

## Entire System Server

If the Entire Operations Monitor runs as a subtask of the Entire System Server, the startup parameters BPSIZE and BPDIRS specify the size of Natural buffer pool. The more space and directory entries that are available in this buffer pool, the fewer the Adabas calls that are made to load Natural objects used by the Monitor.

## Natural

- If the Monitor runs as a separate batch job or task, the same as mentioned under Entire System Server applies for the Natural batch buffer pool.

- Define the necessary Software AG Editor buffer pool large enough to avoid swapping to the EDTWORK data set.

## Adabas

Check the Adabas statistics for pools filling up, number of throwbacks, number of format overwrites and thread use, and adjust the necessary parameters.

Increase the Adabas buffer LBP to enhance the ratio between the number of Adabas calls and the amount of physical IO necessary for them. Reduce the Adabas WORK IO by increasing the NSISN parameter (you may also need to increase the LI parameter).

Watch the usage of the Entire Operations system file(s) carefully:

- Where are the files (AC,UI/NI/MI,DS) located?

- How fast do these devices respond to IO requests?

- What about the parameters ISN reusage and DS reusage?

Spread ASSO and DATA across approximately as many disk devices as there are Adabas threads active. WORK and PLOG should be on separate disk devices.

This section covers the following topics:

- Use LFIOP with Adabas

### Use LFIOP with Adabas

Reorder the Entire Operations system file(s) physically and do this on a regular basis. This puts the records in ISN sequence and accelerates the process of some often-used read processes.

Consider that the Entire Operations Monitor works with the Natural profile parameter setting `WH=ON`. If an Adabas record in the Entire Operations system file(s) is held by an online user and the Monitor has to update it, the Monitor has to wait for the release of that record. In such a situation, check for the contents of the Adabas hold queue for entries pointing to the system files. Adjust all Adabas TNAx time parameters TNAx and the TT parameter to release resources even for those users who are no longer online.

Note
The Adabas `LFIOP` parameter for mainframes is equivalent to the `BFIO_PARALLEL_LIMIT` parameter in Adabas for UNIX and Windows.

## Entire Operations

This section covers the following topics:

- Monitor and Monitor Task Interval

- Monitor Tasks

- Networks

- Job Location

- Activation

- Earliest Start Time

- Input Condition Checking

- Input Condition References

- End-of-Job Checking

- End-of-Job Actions

- Asynchronous Exit Execution

- Symbol Substitution

### Monitor and Monitor Task Interval

Adjust the Entire Operations Monitor and Monitor task wait intervals as necessary.

> Example 1

>   During the online daytime you may only need to have it activating every few minutes, if there are not too many jobs to be executed.

> Example 2

>   If most of your batch jobs are big ones, increase the Monitor wait time as well. You can even change this wait interval by a using a defined API within a Natural program and invoke this program by using Entire Operations itself.

### Monitor Tasks

To keep system overhead for administration of the individual Monitor tasks within reasonable limits, you should not distribute the Monitor among too many unnecessary tasks. The recommended number is 2 to 4 tasks. For the recommended distribution, see Defining a Monitor Task Profile in the Administration documentation.

### Networks

Instead of complex networks with many jobs, use subnetworks. These subnetworks can be defined in jobs of type NET. The wait queues shortens and activation is performed only if all necessary conditions are fulfilled.

### Job Location

Use Natural libraries instead of other JCL media. This decreases the number of requests to the Entire System Server. In addition, you can control total access to these JCL members with Natural Security.

### Activation

Try to keep the time the networks are in the active queue as short as possible, i.e. activate the networks close to their submission time. The number of conditions to be checked by the Monitor decreases.

### Earliest Start Time

Specify an earliest start-time for each network, if possible. Conditions are checked only after that time. Otherwise, the network is activated at midnight (the beginning of the schedule day).

### Input Condition Checking

Any special actions during input condition checking are convenient but may produce overhead. Among them are:

- input conditions dependent on files, job variables, etc.

- input condition user exits, which make excessive Adabas calls.

Avoid the redundant checking of such conditions. It is much more efficient to let dummy jobs wait for such conditions, which are predecessors of several other jobs.

### Input Condition References

Wherever possible, avoid using input condition references other than `RUN`, because they cause a condition check within a time interval, and this is less efficient than a direct `RUN` check.

Note
`RUN` checks are not applicable, if you need an inter-network connection.

### End-of-Job Checking

Each defined check costs performance time, so reduce the End-of-Job checks to the necessary minimum. Avoid complex End-of-Job actions on the `SYSOUT` protocol.

End-of-Job checking user exits may be run in asynchronous mode.

### End-of-Job Actions

End-of-Job action user exits may be run in asynchronous mode.

### Asynchronous Exit Execution

For each End-of-Job checking (EJC) exit and End-of-Job action (EJA) exit you may define asynchronous execution. See also User Exits for End-of-Job Checking and Actions in the User's Guide.

Asynchronous exits will be executed in the dedicated Monitor task(s) for jobs of type NAT. They do not block the handling of End-of-Job checking and End-of-Job action queues within the general-purpose Monitor tasks.

Notes about asynchronous exit execution:

Notes:

1. The network execution logic remains the same, if you define any exit to be executed asynchronously.
2. Exits should not be set to asynchronous execution if they have a short execution time and perform few database and Entire System Server calls.
3. Exits should be set to asynchronous execution if they have a longer execution time and/or perform many database and Entire System Server calls.
4. Note the overhead in network execution elapsed time, which will be caused by more queue changes between Monitor tasks.
5. The elapsed time of single network cannot be shortened by asynchronous exits.
6. The throughput of parallel running networks with excessive exit usage can become better, due to more parallelism.

### Symbol Substitution

In complex productions with often-used JCL skeletons, avoid too much symbol substitution: for example, just assume that a job with 100 symbols is used 500 times a day. Be sure that the use of all parameters is necessary.

### On this page

- Entire System Server
- Natural
- Adabas
- Entire Operations