Decimal overflow implications in ILC applications

ILC applications run outside of the realm of a single language environment, which creates special conditions, such as how the data from each language maps across load module boundaries, how conditions are handled, or how data can be passed and received by each language.

While LE fully supports ILC applications, there can be significant performance implications when using them with COBOL applications. One area to look at is condition handling.

COBOL normally either ignores decimal overflow conditions or handles them by checking the condition code after the decimal instruction. However, when languages such as C or PL/I are in the same application as COBOL, these decimal overflow conditions will now be handled by LE condition management since both C and PL/I set the Decimal Overflow bit in the program mask. This can have a significant impact on the performance of the COBOL application, especially under CICS®, if decimal overflows are occurring during arithmetic operations in the COBOL program.

Notes:

• These languages or features need not be used to affect decimal overflows, their mere presence in the executable code will enable decimal overflows at the time the executable is loaded such as via a dynamic call.
• The C/C++ or PL/I program does not need to be called. Just the presence of C/C++ or PL/I in the load module will cause this degradation for decimal overflow conditions.
• The DLL implementation uses the C/C++ runtime.
• When XML GENERATE, XML PARSE, or JSON GENERATE statements are in the program, the C runtime library will be initialized. Hence, the decimal overflow bit in the program mask will be set even though you do not explicitly have a C or PL/I program in the application. This will also cause the same degradation for decimal overflow conditions. JSON PARSE statement does not require the C runtime library. Therefore, JSON PARSE does not affect the decimal overflow bit in the program mask.
• For the BPXWDYN interface to dynamic allocation, use the alternate entry point BPXWDY2 instead. BPXWDY2 will preserve the program mask.

For a COBOL program using COMP-3 (PACKED-DECIMAL) data types in 100,000 arithmetic statements that cause a decimal overflow condition, the C or PL/I, ILC case was over 99.98% slower than the COBOL-only, non-ILC case.

z15® introduces a way for COBOL programs to suppress the overflows on a per-instruction basis, enabling overflow conditions to be ignored by the hardware even when the Decimal Overflow bit in the program mask is set. In an ILC benchmark compiled where some computations overflowed, performance improved by 27% when compiling at ARCH(13) than at ARCH(12).