This document covers the following topics:
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:
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.
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.
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.
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.
Adjust the Entire Operations Monitor and Monitor task wait intervals as necessary.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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 action user exits may be run in asynchronous mode.
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:
NPR calls.
NPR calls.
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.