This document contains suggestions to avoid unnecessary SRB/TCB switches and reduce CPU overhead for zIIP support and to improve the offload to the ZIIP.
Note
You can use the Component
Switch Statistics (see the Natural system command
ZIIP) to view the list of components that cause TCB switches.
The Natural profile/session parameter MT (maximum CPU time) has the effect that each time
Natural starts a program at Level 1, a z/OS timer service request must be executed. This
forces Natural to switch off from the zIIP. The default setting is MT=60 to
prevent endless loops in Natural applications. Consequently, each time Natural falls back
to a program level of 0, the timer is restarted. This also happens with the
FETCH statement: each time a program is fetched, the timer must be reset.
The default setting is MT=60 to prevent endless loops in Natural
applications. It is recommended to set MT=0 when running a session that
executes many FETCH statements. This will prevent Natural from using timer
macros and avoids unnecessary SRB/TCB switches.
Natural needs to switch off zIIP usage each time a 3GL program is executed, because Natural does not know whether any z/OS service calls are issued in the external subprogram(s).
In addition, Natural is only allowed to offload Natural-written code to a zIIP. User-defined code written in any other language must not be offloaded.
Calling 3GL programs within a Natural loop, forces many SRB/TCB switches, and therefore much CPU overhead. A high share of 3GL code will reduce the offload capabilities of Natural sessions. Such sessions are not suitable for running zIIP-enabled.
Executing an Adabas access statement in Natural, causes at least one WAIT SVC call and forces Natural to switch off from the zIIP. You can reduce the number of switches by exploiting the multi-fetch capabilities of Natural:
| Without Multi-Fetch | With Multi-Fetch | |
|---|---|---|
| Records read | 100,000 | 100,000 |
| Number of switches into SRB mode | 100,000 | 12,500 |
| Total enclave CPU time | 5,389 ms | 958 ms |
For further information on the multi-fetch feature, see Multi-Fetch Clause, in Accessing Data in an Adabas Database in the Programming Guide.
External sorts cannot be processed on zIIP. Therefore, Natural must deactivate zIIP when sending or receiving records from external sorts. In contrast, Natural sorts are processed exclusively on zIIP. Therefore, choosing a Natural sort over an external sort can boost zIIP utilization.
The following example illustrates the difference in zIIP utilization between a Natural sort and an external sort.
| External Sort | Natural Sort | External Sort | Natural Sort | |
|---|---|---|---|---|
| Records sorted | 12,500 | 12,500 | 25,000 | 25,000 |
| Enclave GP time | 95 ms | 3 ms | 141 ms | 4 ms |
| Enclave zIIP time | 71 ms | 121 ms | 134 ms | 259 ms |
| Total enclave CPU time | 166 ms | 124 ms | 275 ms | 263 ms |
| Number of switches into SRB mode | 211 | 0 | 419 | 0 |
Here is a sample Natural profile parameter SORT configuration that
bypasses external sorting and utilizes Natural:
SORT=(WRKSIZE=1000,EXT=OFF)
An increase in the number of switches into SRB mode significantly impacts the
performance of external sorting. You can mitigate unnecessary SRB/TCB switches by
configuring a sort work buffer as a cache buffer using the WRKSIZE keyword
subparameter of the Natural SORT profile parameter.
In the input phase of external sorting, Natural collects an adequate number of input records that fit into the work buffer and sends them to the external sort with just one SRB/TCB switch. Similarly, during the output phase of external sorting, Natural retrieves the appropriate number of sorted records that can fit into the work buffer with a single SRB/TCB switch.
The following example illustrates how the number of SRB/TCB switches involved in
external sort processing decreases as the WRKSIZE buffer values increase.
| WRKSIZE=10 | WRKSIZE=100 | WRKSIZE=1000 | |
|---|---|---|---|
| Records sorted | 25,000 | 25,000 | 25,000 |
| Number of switches into SRB mode | 419 | 41 | 5 |
| Enclave GP time | 143 ms | 135 ms | 131 ms |
| Enclave zIIP time | 158 ms | 151 ms | 147 ms |
| Total enclave CPU time | 301 ms | 286 ms | 278 ms |
Here is an example of the Natural profile parameter SORT, which enables
external sorting with a WRKSIZE buffer size of 1000 KB.
SORT=(WRKSIZE=1000,EXT=ON)
Any work file or printer usage causes I/O interrupts which force Natural to switch off from the zIIP. You can avoid unnecessary switches by defining cache buffers to be used for print and work file I/O processing. These cache buffers are used to keep the data in core as long as possible and read or write data in larger chunks.
The cache buffers are defined with the keyword subparameter PWCSIZE of the profile
parameter ZIIP, for example:
ZIIP=(PWCSIZE=(300,200,300))
The buffer sizes are interpreted in KB. They specify the print buffer, read buffer and write buffer. Buffer sizes of several 100 KB are sufficient.
Primary I/O operations are not subject to caching. Instead, the size of the terminal
I/O buffer is relevant. This buffer is flushed either when it is full or when an I/O
operation is triggered by an INPUT statement.
You can use the Natural profile parameter MAINPR to separate program output from Natural
system output and reroute primary output for CMPRINT to an additional
printer that is processed with a cache buffer.
When your application creates a printout with a line size of 132 characters, a print cache of 132 KB will reduce the SRB/TCB switches for printing by a factor of 1000. This means, Natural will not switch for every line, but only once per 1000 lines or 20 pages.
| WRITE (1) Without Cache | WRITE (1) With Cache | |
|---|---|---|
| Lines written | 10,000 | 10,000 |
| Number of switches into SRB mode | 10,003 | 10 |
| Total WLM enclave CPU time | 386 ms | 68 ms |
For the work file handling, you will get a similar result:
| READ WORK FILE (1) Without Cache | READ WORK FILE (1) With Cache | |
|---|---|---|
| Records read | 10,000 | 10,000 |
| Number of switches into SRB mode | 10,478 | 5 |
| Total WLM enclave CPU time | 641 ms | 305 ms |
You can monitor the usage of the cache buffers by using the Natural system command
BUS.
To monitor buffer cache usage
Issue the following system command:
BUS
A Buffer Usage Statistics report then outputs the sizes used by the cache buffers:
12:50:28 ***** NATURAL BUS UTILITY ***** 2012-04-03 User SAG - Buffer Usage Statistics - OpSYS z/OS No. Name Type Size Used Perc. MaxUsed Perc. MaxSize Perc. ------------------------------------------------------------------------------ 18 PCACHE V 512000 32 0.0 511958 100.0 21 WCACHEO V 307200 32 0.0 306947 99.9 26 WCACHE01 V 512000 32 0.0 511992 100.0 ------------------------------------------------------------------------------ ThrdSize Total 1382656 166593 12.0 2000 54.9 33480 1.6 2000K (in KB) 1351K 163K 742K 33K ------------------------------------------------------------------------------ Nat9995 Natural session terminated normally. |
PCACHE is the cache for all print output.
WCACHEO is the cache for the WRITE WORK FILE
statement.
WCACHEnn is the cache for the
READ WORK FILE statements.
For statements generating output (such as WRITE or WRITE WORK
FILE), only one cache buffer is allocated, also for multiple files. For the
READ WORK FILE statement, there is one buffer allocated per work file.
The buffers are allocated only when used.
For detailed information on the Buffer Usage Statistics, refer to the relevant section in SYSTP Utility in the Utilities documentation.
In batch mode and under TSO, Natural usually allocates an internal buffer with a
GETMAIN or FREEMAIN requests to the operating system. Any
storage request includes an SVC (supervisor call) and requires a switch back to TCB
processing mode.
You can reduce the number of GETMAIN or FREEMAIN requests by
specifying a thread size with the Natural profile parameter THSIZE. Natural will then
allocate the specified amount of space with one GETMAIN and then serve all
buffer requests from the allocated thread storage without calling the operating system
again.
At the end of a Natural session, you can use the Buffer Usage
Statistics report (see the example screen) to check the buffer and thread usage and determine whether
the defined thread size (MaxUsed) is sufficient to allocate all buffers used
by the session.
