Performance considerations. IBM iSeries
Below you will find brief information for CICS for iSeries application programming iSeries. This document provides programming guidance information for experienced programmers who are new to CICS programming and need an introduction to the CICS application programming interface. The document describes CICS/400, which is a transaction server for IBM eServer iSeries systems. The CICS framework is a comprehensive and robust programming environment. It is designed to enable the efficient development and execution of high-volume, transaction-oriented applications. It is used across a wide variety of industries, including banking, finance, insurance, retail, and manufacturing.
Advertisement
Advertisement
Send unformatted data without maps
If your output to a terminal is entirely or even mostly unformatted, you can send it using terminal control commands rather than BMS commands (that is, using an
EXEC CICS SEND command without the MAP or TEXT options). However, these
commands can be less efficient when using 5250 terminals. See “Terminal communication” on page 84.
Performance considerations
This section covers general performance considerations for CICS, including advice relating specifically to CICS in the AS/400 environment. Where this affects application design, you should also consider any possible effects on the portability of the program to CICS in other environments.
CICS and multiprocessor AS/400s
The CICS/400 architecture is generally able to exploit each of the processors in a multiprocessor AS/400 without the need for multiple CICS regions. This is because the CICS/400 architecture uses individual AS/400 jobs for user shells and the dispatch of the jobs is controlled by internal OS/400 dispatching mechanisms.
A simplified explanation follows. An
individual task
is likely to be executed on a specific processor due to internal affinities. Another task running from the same user shell could execute on a different processor. The choice of which processor is dispatched to run the task is controlled by the operating system, not CICS, and uses a combination of priority, eligibility, and cache affinity. Cache affinity is used to dispatch tasks to the processor on which they are most likely to have residual data in cache and, therefore, the processor on which they are likely to experience the best performance.
CICS SIT parameters
There are performance considerations that relate to specific SIT parameter settings.
CICS internal trace (INTTRCCTL) and auxiliary trace
(AUXTRCCTL)
CICS trace is a powerful debugging aid, but there is a significant performance overhead incurred when trace is enabled. This is because of the additional processor time required to generate and record trace data.
The CICS supplied defaults have trace switched off, and it is recommended that it is left off in stable production systems for best performance. If you experience problems that you believe are caused by IBM code however, you will need to provide debugging information which will include CICS traces.
The overhead of CICS auxiliary tracing is greater than that for an internal trace.
CICS files left open count and open timeout (FILECTL)
In the SIT parameter FILECTL:
Element 1 controls the maximum number of files left open to a user shell at task termination.
Element 2 controls how long a file can be kept open by a shell without being referenced.
Each user shell separately opens and closes files, unlike mainframe CICS where the single CICS job opens the files on behalf of all the tasks in the system.
Chapter 5. Designing efficient applications
81
Opening, and to a lesser extent, closing files is a relatively expensive operation in terms of processor cycles. The default setting for this parameter is therefore zero, which means that CICS keeps files open for the user shell once they have been referenced. They remain open until the shell shuts down or the open inactivity limit expires.
Leaving files open saves processor time in opening and closing files, but increases memory use in relation to the number of open files.
The impact on memory use depends on the configuration of your AS/400 and the nature of your application. As an initial estimate, you might regard up to 20 open files per user shell as a threshold. For larger numbers of files, consider using the maximum file open and time out close parameters in conjunction.
Setting the maximum number of open files too low could cause additional opening and closing of files, which then increases the processor use and response time of the transaction.
Note:
CICS allows a task to access more than the maximum number of files defined in the first FILECTL parameter during the processing of that task. A check is made at task termination to see whether the maximum is exceeded; if it has, those files least recently used will be closed. Any files opened to the shell, including those for temporary storage and transient data are eligible for automatic closure.
CICS interval control processing (ITVCTL)
In the interval control parameter (ITVCTL):
Element 1 controls the maximum number of batch shells concurrently active for interval control.
Element 2 controls how many batch shells will be kept active when there is no ongoing interval control processing.
Starting and stopping the batch shells used for interval control processing uses relatively high amounts of processor and elapsed time. To get good response time and efficient processing, you should ensure that sufficient shells exist and are available for reuse.
BMS map set suffixing (DEVCTL)
In the SIT parameter DEVCTL:
Element 3 is set to *DDS by default, enabling map set suffixing when suffixed map sets are in use. When map sets are not suffixed, you can improve performance by setting this element to *NODDS as unnecessary searches are avoided.
COBOL application code
There are performance considerations that relate to the design and implementation of COBOL applications.
COBOL generation options
The performance of a CICS application is influenced by how efficient your application code is, and how the program is compiled. The
COBOL/400 User’s
Guide
describes COBOL/400 compilation and generation options.
Note that, if the program contains SQL statements, the generation options are passed to the SQL precompiler but not to the COBOL compiler.
82
CICS for iSeries Application Programming Guide V5
The CICS/400 CL command CRTCICSCBL allows the use of two generation options that affect performance.
*NORANGE
The default generation option used by the CICS/400 translator is *RANGE.
This causes the compiler to generate code to check that subscripts are within range. For example, it ensures that you are not attempting to reference the 21st element of a 20-element array. If you specify the
*NORANGE option this additional code is not generated. Specifying the
*NORANGE option can give worthwhile performance improvements in programs with significant subscript activity,
*OPTIMIZE
The default generation option used by the CICS/400 translator is
*NOOPTIMIZE. This causes the compiler to perform only standard optimization for the program. If you specify the *OPTIMIZE option, the program object created may run more efficiently and may require less storage. However, specifying the *OPTIMIZE option can substantially increase the time required to compile a program, so you may decide to use this only for production programs.
See page 266 for the format of the CRTCICSCBL command.
ILE C application code
There are performance considerations that relate to the design and implementation of C applications.
ILE C generation options
The CRTCICSC CL command does not support the ILE C optimization parameter
(OPTIMIZE) on the CRTCMOD CL command. You can, however, use the
CHGMOD, CHGPGM, or CHGSRVPGM CL commands to select
OPTIMIZE(*BASIC) or OPTIMIZE(*FULL) before using a module, program, or service program in a production environment.
See page 286 for the format of the CRTCICSC command.
*DEBUG or *NODEBUG
Setting the *DEBUG translator option could affect the performance of your program. The *NODEBUG translator option has no effect on the performance of your program.
EXEC CICS LINK command or host language call
There is a greater processor cost in using an EXEC CICS LINK command to pass control between programs than using a host language call. If your application makes extensive use of, for example, an interface program to access various different file access methods, you may wish to consider the use of a host language call rather than an EXEC CICS LINK command.
When using an EXEC CICS LINK command, the linked to program will have its working or automatic storage initialized every time it is invoked, but this will only occur on the first entry in a run time unit when a host language call is used. In
COBOL/400 applications, this could mean you would need to change the application code to use MOVE statements in the procedure division to initialize fields rather than VALUE clauses in the WORKING STORAGE SECTION.
Chapter 5. Designing efficient applications
83
Terminal communication
These performance considerations relate to terminal communication.
BMS and terminal types
CICS/400 supports both 3270 and 5250 terminals, and there is logic within the
Terminal Control and BMS functions to deal with the differing needs of these devices.
For BMS, CICS creates the appropriate 3270 or 5250 data stream to communicate with the attached device, when that device is connected to the local AS/400.
Terminals attached to remote AS/400 or other processors are dealt with as 3270 devices, and data stream conversion is avoided.
The CICS logic for locally attached devices is designed to avoid data stream conversion wherever possible. The matrix of when data stream conversion is
required is shown in Figure 23.
Figure 23. Data stream conversion
In the case of terminal control, the CICS application sends a 3270 data stream, and
CICS terminal control determines from the device characteristics of the destination unit whether conversion is required.
BMS DATAONLY option
3270 devices can benefit from reduced line traffic by use of the DATAONLY option of the EXEC CICS SEND MAP command.
5250 devices need additional processing to process a DATAONLY request in merging the new data with the existing screen. This option therefore incurs a processor overhead and may not significantly reduce line traffic.
Data stream compression
Depending on definitions in the system initialization table (SIT) and terminal control table (TCT), CICS can compress outbound data being sent to 3270 and 5250 devices. This is of particular relevance to terminals connected to the AS/400 by low-speed synchronous data link control (SDLC) links, where the outbound data stream is typically up to ten times longer than the inbound data stream.
84
CICS for iSeries Application Programming Guide V5
It is possible to reduce the size of the outbound data stream by replacing repeated characters with a Repeat to Address (RA) order. This technique can substantially reduce the amount of outbound data and therefore give quicker transaction response time.
The
CICS/400 data stream compressor
causes all outbound CICS data streams to be parsed for repeating sequences of the same character, replacing them with equivalent RA orders. These are automatically expanded to the correct size at their destination as this is an integral part of data-stream architecture.
This facility is only effective for CICS generated data streams. You may also choose to use the
AS/400 3270 data stream optimizer
. This optimizes data streams generated by the AS/400 system through non-CICS activity. It uses similar methods to the CICS/400 compressor, and makes additional size reductions by maintaining details of screen images and avoiding unnecessary sending of unchanged data. Using this facility may cause an increase in processor activity.
The AS/400 data stream optimizer is only effective for AS/400 generated 3270 data streams targeted for remotely attached 3270’s, Distributed Host Command Facility
(DHCF) devices, Network Routing Facility (NRF) devices, and 3270 TELNET devices.
Chapter 5. Designing efficient applications
85
86
CICS for iSeries Application Programming Guide V5
Download
Advertisement
Key features
Transaction server
Programming environment for transaction-oriented applications
High-volume transaction processing
Robust and comprehensive
Widely used across industries
Supports COBOL, ILE COBOL and ILE C
Frequently asked questions
CICS for iSeries is a transaction server that provides a programming environment for developing and running high-volume, transaction-oriented applications on IBM eServer iSeries systems.
CICS for iSeries supports COBOL, ILE COBOL, and ILE C.
CICS for iSeries offers a range of benefits, including high-volume transaction processing, robust security, and a comprehensive programming environment.