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:
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 Software AG Editor buffer pool large enough to avoid swapping to the EDTWORK data set.
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:
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 all Adabas TNAx time parameters TNAx and the TT parameter 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.
This section covers the following topics:
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.
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.
Instead of complex networks with many jobs, use subnetworks. These subnetworks 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 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. 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:
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.