Natural CICS Performance Considerations

#### Search Results

Search

# Natural CICS Performance Considerations

This document contains guidelines for setting up Natural in a CICS environment.

It covers the following topics:

- Choosing between the Roll Server and Roll Facilities

- Choosing the Roll Facility

- Shared Storage Threads versus GETMAINed Threads

- CICS Parameter Settings

- Line Compression Systems

- Pseudo-Conversational versus Conversational Transactions

- Natural and Adabas

- CICS Monitoring Products

## Choosing between the Roll Server and Roll Facilities

The Roll Server is versatile and scalable when used for saving and restoring Natural session data over a screen I/O. You must use the Natural Roll Server when running Natural in a CICSPlex or Parallel Sysplex environment, and you can use the Roll Server locally in a single CICS region. The Roll Server is able to handle a large number of concurrently executing Natural sessions. However, using roll facilities to handle a large number of concurrently executing Natural sessions may cause resource contention.

Natural installations in different CICS regions can share the same Roll Server, provided they use the same subsystem ID, because the Roll Server relates to a specific subsystem. If the terminal IDs in CICS regions with Natural installations that share the same Roll Server are not unique across these regions, use the `NTCICSP` parameter `UNITID=ON` to ensure that a unique session ID can be created or use separate Roll Servers for each CICS region with different subsystem IDs.

In a non-Parallel-Sysplex environment, the Roll Server can operate without a roll file, using only the in-storage Local Roll Buffer (LRB) that is contained in a z/OS memory object allocated above the bar. In that case, the LRB should have at least as many slots as the maximum number of concurrently executing Natural sessions. The slot size should be at least large enough to accommodate an average compressed Natural thread. If any “reserve” slots are available, threads that do not fit into a single LRB slot will occupy additional slots.

If Natural for zIIP is installed, the Roll Server schedules thread compression to run on a zIIP.

To avoid setting up and maintaining a Roll Server for Natural installations and CICS regions with a small number of concurrently executing Natural sessions, you can use one of the supported roll facilities described in this section.

For more information about the Natural Roll Server, see Operations > Natural Roll Server Functionality.

## Choosing the Roll Facility

This section descrcibes the supported roll facilities. To specify a roll facility for a thread group, use the `PRIMERF` parameter of the `NCMTGD` macro.

Software AG does not recommend using a roll facility for Natural installations and CICS regions with a large number of concurrently executing Natural sessions. In such a case, you can use the Natural Roll Server.

This section covers the following topics:

- Using CICS Main Temporary Storage

- Using CICS Auxiliary Temporary Storage

- Control Interval for VSAM Roll Files and Auxiliary Temporary Storage

- VSAM Roll Files versus CICS Temporary Storage

- Using VSAM RRDS Roll Files

### Using CICS Main Temporary Storage

With CICS main temporary storage specified as the roll facility (`NCMTGD` parameter `PRIMERF=MAIN`), no VSAM I/O activity or communication to a temporary storage server is required on rolling. Therefore, using `PRIMERF=MAIN` is faster than `PRIMERF=AUX`. Due to the amount of used main storage, some tuning may be required.

Main temporary storage is allocated in 64-bit (above-the-bar) storage, controlled by the CICS `TSMAINLIMIT` system initialization parameter and the z/OS `MEMLIMIT` parameter. The thread data to be rolled out is split into chunks with a maximum size of 32 KB.

However, if you specify `MEMOBJR=ON` (default) with the `NTCICSP` macro in addition to `PRIMERF=MAIN`, the thread data to be rolled out is copied in a single operation into above-the-bar shared DSA (GSDSA) storage as a contiguous piece of storage.

### Using CICS Auxiliary Temporary Storage

When Natural CICS Interface uses auxiliary temporary storage as the roll facility (`NCMTGD` parameter `PRIMERF=AUX`), the control interval size for the file being used must be at least 4 KB. If auxiliary temporary storage is not available, main temporary storage is used instead.

If you use VSAM roll files (`NCMTGD` parameter `PRIMERF=VSAM`) and the defined VSAM roll files become full or unusable during a CICS session, Natural CICS Interface uses auxiliary temporary storage.

You must increase the number of VSAM buffers defined by the CICS system initialization parameter `TS` to a reasonable value to reduce the number of physical I/O operations. Check he CICS statistics for bottlenecks in this area.

### Control Interval for VSAM Roll Files and Auxiliary Temporary Storage

When using VSAM files or auxiliary temporary storage as the roll facility (`PRIMERF=VSAM` or `PRIMERF=AUX`), specify the largest possible control interval size of 32 KB to minimize the number of I/O operations and the CPU overhead necessary to perform the rolling. You may specify a control interval size of less than 32 KB for better exploitation of disk tracks or the usage of virtual storage for the VSAM buffers.

### VSAM Roll Files versus CICS Temporary Storage

With the same CISIZE/record size, temporary storage causes less CPU overhead than VSAM roll files:

To write n records to temporary storage you have to issue n +1 CICS requests (that is, 1 for `DELETQ` and n for `PUTQ`) while you have to issue 2 n requests for VSAM roll files because of the VSAM transaction logic: n times (`READ` for `UPDATE` plus `REWRITE`).

For VSAM update requests, a physical I/O is always performed, whereas for temporary storage (`AUX`) records, buffering takes place, so that in many cases, records to be read are still found in the buffers.

However, CICS temporary storage may become a bottleneck when it is also being used by other applications.

VSAM roll files for Natural can overcome this situation (although at the expense of additional VSAM buffer space) especially when I/O contention can be avoided. VSAM roll files with optimum/maximum CISIZE/record size are particularly efficient when this record size cannot be specified for the CICS temporary storage file due to other requirements.

CICS temporary storage should be used whenever it can be dedicated to Natural. If CICS temporary storage is also used by other applications, you should evaluate whether the Natural performance is better when using VSAM roll files.

If Natural with CICS temporary storage does not perform worse, you should choose CICS temporary storage as roll facility and use the "saved" VSAM roll file buffer space for more TS buffers or for an additional thread.

### Using VSAM RRDS Roll Files

The VSAM roll files should be considered for normal CICS VSAM file tuning, for example, `BUFNO` and `STRNO` parameters in the FCT. The CICS shutdown statistics should be checked for bottlenecks in this area.

As the roll files serve as a kind of page data set for Natural, everything which slows down the Natural rolling should be avoided, as there is journaling and logging; dynamic transaction backout (DTB) and forward recovery for roll files is useless and only causes overhead.

#### In MRO Environments

For performance reasons the VSAM roll files should be defined in the same CICS system in which the Natural applications are running; MRO function shipping should not be invoked. CICS local shared resources (LSR) can be used if there are enough buffers available.

#### Separate LSR Pool for Natural

The definition of a separate LSR pool for Natural roll files is recommended, with the number of strings (STRNO) greater than the number of threads. The number of buffers should also be greater than the number of threads. A greater number of buffers increase the look-aside hit ratio.

## Shared Storage Threads versus GETMAINed Threads

This covers section the following sections

- Storage Usage

- Controlling Storage Usage

- Rolling

- Considerations for CICS/TS

- Conclusion

### Storage Usage

Shared storage threads are pre-allocated during Natural CICS system initialization, which means that the storage covered by these threads is dedicated to the Natural CICS system, regardless of whether there are active sessions or not. On the other hand, `GETMAIN`ed threads only exist while the CICS task is active.

### Controlling Storage Usage

With shared storage threads (`TYPE=SHR`), Natural under CICS always uses what has been pre-allocated during the initialization of Natural; therefore, the size of storage used by Natural threads is easily predictable. For `GETMAIN`ed threads (`TYPE=GETM`), however, the actual storage used depends on the number of Natural sessions that are currently active.

Although Natural itself has no mechanism for setting the maximum number of `GETMAIN`ed threads, this can be controlled by grouping the Natural transaction codes into a `TRANCLASS`. When a transaction code belongs to such a class, the maximum number of parallel tasks can be regulated by the `MAXACTIVE` parameter in the `TRANCLASS` definition.

### Rolling

When a Natural session releases its shared storage thread, session data are kept in the thread in uncompressed format, unless another session needs to use this particular thread. If so, the new session is responsible for saving the old session's data.

Such an activity is called "deferred rolling". It enables you to eliminate rolling entirely, provided that the number of available threads is greater or equal to the number of concurrently active Natural sessions.

Conversely, sessions that use `GETMAIN`ed threads always save their data prior to the `FREEMAIN` operation at CICS task termination, which leads to a roll overhead regardless of the number of concurrently active Natural sessions.

In environments with high volumes of Natural transactions, there is practically no difference between saving session data via the "immediate" or the "deferred" rolling method.

In busy Natural environments with a high ratio of Natural sessions to program storage threads, there is more roll-in/roll-out overhead, since these threads are shared by several Natural sessions. A potential problem in this situation is thread contention caused by Natural tasks with long-running Adabas requests; that is, with many Adabas calls.

To prevent such tasks from "locking" a thread for too long, they can be forced to release their thread by using Natural profile parameter `DBROLL` appropriately.

For `GETMAIN`ed threads, however, contention between two or more Natural sessions never occurs, since a `TYPE=GETM` thread belongs exclusively to the Natural session it was allocated for.

`TYPE=GETM` threads can thus be considered "single-use" resources that are never shared, whereas `TYPE=SHR` threads can be considered "multi-use" resources that may be shared.

### Considerations for CICS/TS

The most important feature of CICS/TS in z/OS is transaction isolation, which means that a task's storage can be protected against other tasks.

To take advantage of this facility with Natural, `TYPE=GETM` threads should be used, since these threads are subject to transaction isolation, whereas "shared" `TYPE=SHR` threads are not. Also additional CICS overhead occurs for `TYPE=SHR` threads with CICS/TS.

While the thread selection algorithm for `TYPE=GETM` threads is trivial (when a Natural task is started, a thread is allocated via CICS `GETMAIN`), for `TYPE=SHR` threads, it is more complicated: the Natural threads environment is managed by the environment-dependent nucleus (queueing and balancing), whereas CICS does not know anything about Natural threads. In contrast to `TYPE=GETM` threads, where CICS would release the thread at the latest at the end of the task, with `TYPE=SHR` threads, Natural has to assign/release them to/from their sessions. In order to do so, Natural maintains a list of thread control blocks (TCBs).

Although Natural always keeps an exit active to be able to release session resources unknown to CICS (for example, `TYPE=SHR` threads) in the case of abnormal task termination, situations may occur where a Natural task terminates without its thread being marked as free in the associated TCB (for example, if an `EXEC CICS ABEND CANCEL` request has been issued in a non-Natural program called by Natural, or if Natural sessions have been flushed by any `KILL` transactions of a performance monitor).

To prevent problems with threads inadvertently left busy, Natural under CICS always checks in its thread selection algorithm whether the CICS task associated to a busy thread is still existing; if not, the thread is released.

With CICS versions prior to CICS/TS, this checking for active CICS tasks was done by control-block jumping, which means that Natural was checking for an active task by testing the consistency of the task's EISTG, TCA and TQE control blocks. With CICS/TS, because of transaction isolation, the storage of another task may not be accessible at all.

To accomplish this function in CICS/TS, the environment-dependent nucleus issues an `EXEC CICS INQUIRE STORAGE TASK()` request for any thread identified as busy in the thread selection routine. This means that there may have been some CICS requests before the task is finally ENQueued for thread resources. The same CICS command is also used for the serialization of Natural sessions (for example, deferred rolling of `TYPE=SHR` threads).

### Conclusion

Both `TYPE=SHR` and `TYPE=GETM` threads have their advantages and disadvantages. However, with CICS/TS, `TYPE=GETM` threads are preferred, because of:

- the support of transaction isolation (z/OS only),

- more CICS-like tuning possibilities,

- worse performance of `TYPE=SHR` threads.

## CICS Parameter Settings

CICS SIT parameters `AMXT` and `CMXT` should be used to control the number of concurrent Natural tasks.

The number specified should be greater than the number of threads. You should also consider to specify a separate transaction class with a suitable `CMXT` parameter for asynchronous Natural tasks and for Natural Advanced Facilities spool tasks so as to prevent logouts of "normal" Natural terminal tasks by too many of such "background" tasks occupying threads. Special thread groups can be defined for these transactions.

CICS dumps for Natural transactions should be suppressed, unless requested from Software AG personnel for debugging purposes. Natural itself generates dumps (via `EXEC CICS DUMP`) for non-program check abends, and also for program checks if the Natural session parameter `DU` is set to `ON`. When no Natural dump is generated, a CICS dump is redundant and just causes overhead (particularly when creating a system/region dump, since the whole CICS system is halted until the snap dump is completed).

CICS trace is essential when analyzing problems, although it introduces system overhead. Also CICS performance monitoring tools and accounting packages cause system overhead of up to 30 percent and more. Some packages internally turn on the CICS trace and then intercept it. You should be aware of this potential system overhead. Also remember that Natural CICS Interface uses the CICS command level application programming interface: CICS command level requests produce much more trace entries (apart from other overhead) than CICS macro level requests.

## Line Compression Systems

Natural itself optimizes its data streams by means of RA (repeat to address) and other techniques as screen imaging etc. If other line compression systems are installed, the Natural transactions should be excluded from being processed by these systems, as this would introduce overhead without achieving any benefit.

## Pseudo-Conversational versus Conversational Transactions

When resuming a session, conversational Natural tasks are locked to their initial thread, which means that a conversational task has to wait for this thread if it is currently not available. Pseudo-conversational Natural tasks, however, are flexible to roll into any available thread.

In other words, the "classical" advantage of conversational tasks - less I/O for saving/restoring data over screen I/O operations - does not apply for Natural because of its thread technique.

## Natural and Adabas

Since a Natural task in CICS waits for completion of an Adabas call, the servicing Adabas region/partition should always have higher priority than the CICS region/partition to minimize wait time.

## CICS Monitoring Products

CICS monitoring products may offer facilities to purge CICS tasks, bypassing any abnormal termination exit set by the application.

| Warning: Such facilities should not be used to cancel Natural tasks, as Natural may not be able to clean up its resources, and, even worse, the Natural CICS system may be left in an inconsistent state depending on what this task was doing.

To cancel Natural sessions, the Cancel/Flush Session functions of the SYSTP utility should be used instead; see the relevant section in the Natural Utilities documentation for details.

### On this page

- Choosing between the Roll Server and Roll Facilities
- Choosing the Roll Facility
- Shared Storage Threads versus GETMAINed Threads
- CICS Parameter Settings
- Line Compression Systems
- Pseudo-Conversational versus Conversational Transactions
- Natural and Adabas
- CICS Monitoring Products