This document contains guidelines for setting up Natural in a CICS environment.
It covers the following topics:
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.
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:
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.
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.
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.
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.
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.
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.
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.
This covers section the following sections
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,
GETMAINed threads only exist while the CICS task is
active.
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 GETMAINed
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
GETMAINed 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.
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 GETMAINed 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 GETMAINed 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.
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).
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 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.
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.
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.
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 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.