Performance Considerations

This document covers the following topics:


Overview

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

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 Editor Buffer Pools large enough to avoid swapping to the EDTWORK dataset. For further information on Editor Buffer Pools, see the Installation Notes.

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 IOs necessary for them. Reduce the Adabas WORK IOs 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:

  • On which disks are the components of these 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.

Use LFIOP with Adabas 5.2

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.

Be aware that the Entire Operations Monitor is working with 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, he has to wait for the release of that sentence. In such a situation, check for the contents of the Adabas hold queue for entries pointing to the system files. Adjust Adabas time parameters TNAx and TT to release resources even for those users who are gone.

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

Entire Operations

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 Using the Monitor Task Profile in the Administration documentation.

Networks

Instead of complex networks with many jobs, use sub-networks. These sub-networks can be defined in jobs of type NET. The wait queues decrease 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 or 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 these 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. In particular, 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.

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 NPR calls.
  3. Exits should be set to asynchronous execution if they have a longer execution time and/or perform many database and NPR calls.
  4. Please not 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.