When you run with Language Environment® on CICS®, there are several tuning actions you can take to optimize performance. This section covers:
If Language Environment is active in a CICS address space, the runtime libraries of the native language, such as COBOL or PL/I, are not needed. This means that CICS has a single interface to all the language run times.
One way to improve performance when running programs with Language Environment is to reduce the number of GETMAINs and FREEMAINs required, to manage the storage that Language Environment uses. Two system initialization parameters can be used to minimize the number of GETMAINs and FREEMAINs that CICS performs on behalf of Language Environment:
You can use these two options together in any combination.
You can check the benefit of these functions by running a CICS storage report to show the number of GETMAINs and FREEMAINs in a region when either or both of the functions are active, and comparing the results with previous runs.
You can optionally activate Language Environment's automatic storage tuning feature for CICS by setting the CICS system initialization parameter AUTODST to YES. When this function is active, Language Environment monitors each main program execution, and notes if any additional storage had to be allocated for the program while it was active. At the end of each program execution, if any additional storage had to be allocated, Language Environment retains this information. Next time the program is executed, Language Environment increases the initial storage allocation to include this extra storage. This process helps to minimize the number of GETMAINs and FREEMAINs that CICS has to perform.
Automatic storage tuning is particularly helpful for programs that issue many dynamic calls, as such programs can easily exceed their initial storage allocations. It also removes the need to tune storage manually for individual COBOL programs.
However, you should be aware that once Language Environment has increased the initial storage allocation for a program, it is never decreased. If a program execution requires an unusually large amount of storage, perhaps because the user has activated a seldom-used function of the program, this amount of storage is allocated for all subsequent executions of the program. So in rare cases, you can find that automatic storage tuning leads to an excessive allocation of storage for some programs.
You can alter the behaviour of the automatic storage tuning mechanism using the Language Environment storage tuning user exit CEECSTX. The user exit can enable or disable automatic storage tuning for a particular program, and you might find this useful if you have an application whose storage needs vary greatly between different executions. It can also provide the starting values for initial storage allocation, and you can use it to limit the maximum amount of storage that Language Environment will allocate during the automatic storage tuning process.
If the CEECSTX user exit was previously used as your Language Environment storage tuning method, you might find that the automatic storage tuning mechanism provides the same function, without the user exit. You need to decide which mechanism to use as your main storage tuning method, because when you are running CICS with automatic storage tuning, the CEECSTX user exit has limited function. Automatic storage tuning operates by monitoring storage allocations, whereas the storage tuning user exit CEECSTX monitors the actual storage used by the user application program. Despite this, automatic storage tuning incurs less overhead than the tuning method based on the CEECSTX exit. Also, automatic storage tuning provides tuning for each initial program invoked by a transaction, while the CEECSTX exit provides tuning for only those programs contained in the table that the exit uses as its input. This means that automatic storage tuning can provide a greater benefit by tuning the storage used by more programs.
For more information about CEECSTX, see the Language Environment for z/OS® Customization Guide.
The system pathlength increases when a CICS application invoked by Language Environment issues an EXEC CICS LINK request. Repeated EXEC CICS LINK calls to the same program invoked by Language Environment result in multiple GETMAIN/FREEMAIN requests for run-unit work areas (RUWAs).
Using the system initialization parameter RUWAPOOL(YES) results in the creation of a run-unit work area pool during task initialization. This pool is used to allocate RUWAs required by programs invoked by Language Environment. This reduces the number of GETMAINS and FREEMAINS in tasks that perform many EXEC CICS LINKS to programs invoked by Language Environment.
For more information about the RUWAPOOL system initialization parameter, see the CICS System Definition Guide.
The default Language Environment run time options for CICS are ALL31(ON) and STACK(ANY). This means all programs that require Language Environment must be capable of addressing storage above the line (must be AMODE(31)) when Language Environment is enabled.
To allow AMODE(24) programs to run in a Language Environment-enabled CICS region, ALL31(OFF) and STACK(BELOW) can be specified for those programs that must run below the 16MB line. However, if you globally change these options so that all programs use them, large amounts of storage will be allocated below the line, which can cause a short-on-storage condition. ALL31(OFF) causes Language Environment to acquire some control blocks, such as the RUWA, both above and below the 16MB line, and so additional GETMAINs and FREEMAINs are needed to manage the duplicate control blocks.
There is no need to specify ALL31(OFF) as long as the program in question is the initial program invoked by a transaction, because Language Environment will acquire storage for the enclave (program) in the correct AMODE automatically. The exception is an AMODE(31) program that dynamically calls an AMODE(24) program. In that case, the dynamically called AMODE(24) program needs to specify ALL31(OFF).
When each dynamic link library (DLL) is first loaded, the cost of initialization can be determined by the size of writable static area required by the DLL. Initialization costs can be reduced by removing unnecessary items from the writable static area.
When using DLLs, you should consider the following:
The Language Environment runtime option TERMTHDACT controls the type and amount of diagnostic output produced by Language Environment for an unhandled error.
Using TERMTHDACT(DUMP), TERMTHDACT(TRACE), TERMTHDACT(UADUMP), or TERMTHDACT(UATRACE) can create a significant overhead in a production environment. These settings can cause large amounts of traceback and Language Environment dump data to be written to the CESE transient data queue.
If a traceback or CEEDUMP is not needed by the application environment, use TERMTHDACT(MSG) to eliminate the performance overhead of writing formatted CEEDUMPs to the CICS transient data queue CESE. If the traceback or CEEDUMP is required by the application, specify the CICSDDS option of TERMTHDACT to direct the Language Environment diagnostic output to the CICS dump dataset, rather than to the CESE transient data queue.