OPTIONS AND TUNING CONSIDERATIONS - IBM Mainframe

You may have a customized system that requires certain options for optimum performance. Check with your systems programmer to ensure that installed options are not required before changing defaults.

The tuning methods and performance information discussed here are intended to help you select from various VS COBOL II options for compiling and running your programs. Use these performance tips to tune the run-time environment for improving program performance. This section includes:

  • Compiler options that affect run-time performance
  • Run-time options that affect performance
  • Other tuning considerations
  • Other product considerations
  • Performance tuning worksheet

Compiler Options That Affect Run-Time Performance

  • AWO - The AWO compiler option allows the file buffer to be written to the output device. When the compiler option is specified, the APPLY WRITE-ONLY clause is in effect for all files within the program that are physical sequential with V-mode records. Using the AWO option can result in performance savings since this will generally result in fewer calls to Data Management Services to handle the I/O.
  • DYNAM - The DYNAM compiler option dynamically loads subprograms invoked through the CALL statement at run time. When using the DYNAM option, you can free virtual storage that is no longer needed by issuing the CANCEL statement. You pay a slight performance penalty using DYNAM since the call must go through a library routine.
  • FASTSRT - The TASTSRT compiler option specifies that the IBM DFSORT product (or equivalent) will handle all of the I/O. FASTSRT eliminates the overhead of returning to VS COBOL II after each record is processed. Using FASTSRT is recommended when direct work files are used for the sort work files. Not all sorts are eligible for this option.
  • NUMPROC(PFD), (NOPFD), (MIC) - Use this compiler option for sign processing when coding numeric comparisons. NUMPROC(PFD) generates significantly more efficient code for numeric comparisons. For most references to COMP-3 and DISPLAY numeric data items, using NUMPROC(MIG) and NUMPROC(NOPFD) causes extra code to be generated because of sign "fix up1" processing. This extra code may also inhibit some other types of optimizations. When using NUMPROC(PFD), the compiler assumes that the data has the correct sign and bypasses the sign "fix up" process. Because not all external data files contain the proper sign for COMP-3 or DISPLAY signed numeric data, using NUMPROC(PFD) may not be applicable for all programs. For performance-sensitive applications, the use of NUMPROC(PFD) is recommended whenever possible. For non-eligible programs, using NUMPROC(MIG) has less sign fix up processing than NUMPROC (NOPFD).
  • OPTIMIZE - Use OPTIMIZE to ensure your code is optimized for better performance. Generally results in more efficient run-time code. OPTIMIZE requires more processing time for compiles than NOOPTIMIZE. NOOPTIMIZE is generally used during program development when frequent compiles are necessary, and it also allows for easier debugging. For production runs, however, the use of OPTIMIZE is recommended.
  • RENT - Use the RENT compiler option to generate a reentrant program. Using RENT enables the program to be placed in shared storage (LPA/ELPA) for running above the 16 MB line on an extended addressing system. Using RENT generates additional code to ensure that the program is reentrant. The RESIDENT compiler option must be used with RENT.
  • RESIDENT - The RESIDENT compiler option specifies that all COBOL library routines, except IGZEBST, are to be loaded dynamically at run time. The RESIDENT compiler option supports these features which can provide storage benefits like running above the 16 MB line on an extended addressing system, using dynamic calls and sharing the library. You pay a slight performance penalty with the RESIDENT compiler option due to the overhead of locating and loading the library routines at run time. The RESIDENT compiler option provides full function VS COBOL II support. The NORESIDENT compiler option does not support running on CICS, running above the 16 MB line on an extended addressing system, dynamic calls, debugging with the TEST compiler option and sharing the library. Although the individual application path length may be slightly longer when using the RESIDENT compiler option, the overall system performance will usually be better when the environment is properly tuned. Check with your systems programmer to verify that the most efficient tuning options have been installed.
  • SSRANQE - The SSRANGE option verifies that all subscripts, indexes, and reference modification expressions are within proper bounds. There are no performance advantages. SSRANGE generates additional code for verifying subscripts. In general, if you only need to verify the subscripts a few times in the application instead of at every reference, coding your own checks may be faster than using the SSRANGE option. SSRANGE can be turned off at run time with NOSSRANGE. For performance-sensitive applications, the use of NOSSRANGE is recommended.
  • TEST - The TEST option enables the program to be run under the debug tool. There are no performance advantages. Since the TEST compiler option generates additional code, it can cause significant performance degradation when used in a production environment. TEST forces the NOOPT1MIZE option into effect. For production runs, the use of NOTEST is recommended.
  • TRUNC(STD), (OPT), (BIN) - This compiler option creates code that will truncate the receiving fields of arithmetic operations. TRUNC(OPT) does not generate extra code and generally improves performance. Both TRUNC(BIN) and TRUNC(STD) generate extra code whenever a BINARY data item is changed. TRUNC(BIN) is usually the slowest of these options. TRUNC(STD) conforms to the COBOL 85 Standard, whereas TRUNC(BIN) and TRUNC(OPT) do not. When using TRUNC(OPT), the compiler assumes that the data conforms to the PICTURE and USAGE specifications. For performance-sensitive applications, the use of TRUNC(OPT) is recommended whenever possible.

Run-Time Options That Affect Performance

  • AIXBLD - AIXBLD allows a VS COBOL II program to build alternate indexes at run time.There are no performance advantages.Using this option may adversely affect an application's run-time performance. Using Access Method Services to build alternate indexes before running the VS COBOL II application and then using the NOAIXBLD run-time option is recommended.
  • LIBKEEP - LIBKEEP causes the run-time library routines to remain in memory between calls to COBOL RESIDENT main programs from non-COBOL programs. Using LIBKEEP will reduce part of the initialization and termination overhead incurred when programs are loaded into memory. LIBKEEP can only be used with the RESIDENT compiler option in non-CICS environments.
  • RTEREUS - The RTEREUS run-time option initializes the run-time environment for reuse when the first COBOL program is invoked. RTEREUS improves performance because the environment is not terminated and rebuilt each time a COBOL program is invoked. Because of the effect that the STOP RUN statement has on the runtime environment, you should change all STOP RUN statements to GOBACK statements in order to get the benefit of RTEREUS. RTEREUS may not be applicable to all environments. RTEREUS affects the semantics of a COBOL main program, meaning that storage acquired when the application executes will not be freed. Main programs are considered subprograms entered in the last-used state.
  • SSRANGE - The SSRANGE runtime option activates additional code generated by the SSRANGE compiler option to verify that all subscripts, indexes, and reference modification expressions are within proper bounds. The SSRANGE run-time option activates additional code generated by the SSRANGE compiler option. Using this option may adversely effect an application's run-time performance. In general, if you only need to verify the subscripts a few times in the application instead of at every reference, coding your own checks may be faster than using the SSRANGE option. SSRANGE can be turned off at run time with NOSSRANGE. For performance-sensitive applications, the use of NOSSRANGE is recommended.
  • WSCLEAR - WSCLEAR clears all External Data records acquired by a program, and the working storage acquired by a RENT program, to binary zeroes (except where value clauses are specified). Using WSCLEAR may result in a small amount of overhead at run time.

Other Tuning Considerations

  • Space management tuning - Space management tuning affects the way storage is managed for application programs while they run. Space management tuning can reduce the overhead involved in getting and freeing storage for the application program. The space manager was designed to free blocks of storage when they are no longer needed. Space management tuning can be detrimental if the last block of storage does not contain enough free space to satisfy a storage request by a library routine. To avoid a detrimental situation, the SPOUT run-time option can help you determine the values to use for an application program. Use the value returned by the SPOUT option for the initial storage block size on the IGZTUNE macro for both the INIBLOW and the INIABOV parameters. In an all VS COBOL II environment, this will prevent a storage management problem. However, if the application contains a mixture of OS/VS COBOL programs and VS COBOL II programs that are being called frequently, the SPOUT option may not indicate a need for additional storage. Increasing the initial storage block size on the IGZTUNE macro can also eliminate some space management activity in this mixed environment.
  • Calling ICZERRE - Calling IGZERRE will set up a reusable run-time environment. It allows a non-COBOL program to initialize the COBOL run-time environment. Calling IGZERRE improves performance because the environment is not terminated and rebuilt each time a COBOL program is invoked from a non-COBOL main program. The use of STOP RUN will return control to the program that called the program that invoked the IGZERRE initialization. Calling IGZERRE affects the semantics of a COBOL main program, which means storage, acquired when the application executes will not be freed. Main programs are considered subprograms entered in the last-used state.
  • Optimized Entry/Exit for NORENT Subprograms - VS COBOL II programs compiled with RES, NORENT and run with the NOSTAE run-time option exhibit improved performance when called multiple times from non-COBOL programs (including non-COBOL programs in a reusable run-time environment) or by a static CALL from OS/VS COBOL "programs. Performance is improved because of optimized entry/exit logic made possible through the ability to directly access the run-time control blocks through the called RES, NORENT subprogram's object code. The performance improvement occurs only when the following conditions are met. If any of these conditions are not met, normal nap-optimized entry/exit logic is used:
  • The called VS COBOL II subprogram must be compiled RES, NORENT.
  • The NOSTAE run-time option is specified.
  • COBTEST is not being used when you run the application.
  • The called VS COBOL II subprogram is in last-used state (meaning it has been previously initialized).

Other Product Considerations

  • Mixing OS/VS COBOL and VS COBOL II - If the application program is an OS/VS COBOL program using the VS COBOL II library or if the application program has a mixture of OS/VS COBOL and VS COBOL II, there will be some degradation at run time. Using an OS/VS COBOL program compiled with the RESIDENT option and using the VS COBOL II Library can result in performance degradation at run time. Converting the entire application to VS COBOL II will eliminate mixed environment degradation.
  • Calling COBOL from a non-COBOL program - If the first program in the application is not COBOL, there can be significant degradation if COBOL is repeatedly called since the COBOL environment must be initialized and terminated each time a COBOL main program is invoked. This overhead can be reduced by using one of the following:
  • Call the first program from a COBOL stub program (a program that just contains a call statement to the original first program).
  • Call ILBOSTPO from the first program to make it appear as the COBOL main program (this is provided for compatibility with OS/VS COBOL; calling IGZERRE is preferred over calling ILBOSTPO).
  • Use the run-time option LIBKEEP.
  • Use run-time option RTEREUS to initialize the COBOL environment for reuse, making all COBOL main programs become subprograms
  • Call IGZERRE from the first program to make it appear as the COBOL main program and to initialize the COBOL environment for reuse.
  • IMS - If the application is running under the Information Management System (IMS), preloading the application program and the library routines can help to reduce the load/search overhead, as well as reducing the I/O activity. For better system performance, the RENT and RESIDENT compiler options should be used and the applications and library routines preloaded when possible.
  • CICS - If the application is running under Customer Information Control System (CICS), converting EXEC CICS LINKs to COBOL CALLs can improve transaction response time and reduce virtual storage usage. VS COBOL 11 supports static calls to VS COBOL II subprograms containing EXEC CICS commands. Under CICS/MVS Version 2 Release 2.1 and CICS/ESA, VS COBOL II supports dynamic calls to VS COBOL II programs containing EXEC CICS commands. VS COBOL II does not support calls to or from OS/VS COBOL programs in a CICS environment. You must use EXEC CICS LINK to perform calls to or from OS/VS COBOL programs.

Performance Tuning Checklist

This worksheet will help you evaluate your program's performance. If you answer yes to each question, you are probably increasing your performance. However, be sure you understand the function of each option before considering the performance trade-off. You may prefer function over increased performance in many instances.

  • Are you using the A WO option when possible?
  • Are you using NODYNAM?
  • When using direct work files for the sort work files, have you selected the FASTSRT option?
  • Are you using NUMPROC(PFD) when possible?
  • Are you using OPTIMIZE for production runs?
  • Are you using NORENT?
  • Are you using NORES?
  • Are you going NOSSRANGE for production runs?
  • Are you using NOTEST for production runs?
  • Are you using TRUNC(OPT) when possible?
  • Have you built alternate indexes to the Access Method Services and then used NOAIXBLD?
  • Are you using the LIBKEEP option?
  • Are you using RTEREUS when a non-COBOL driver repeatedly calls a COBOL program?
  • Have you used NOWSCLEAR?
  • Was Space Management Tuning used?
  • Have you used the SPOUT option to select the correct values?
  • For a non-COBOL driver repeatedly calling COBOL, have you used a Call to IGZERRE?

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM Mainframe Topics