RTIBIND and the IBM Run Time Instrumentation Profiler
The IBM Run Time Instrumentation (RTI) Profiler is a performance analysis tool to collect and report on the execution time CPU performance characteristics of your batch z/OS applications.
The RTIBIND option controls whether to rebind your modules with the RTI program modules to enable the RTI performance profiling reports to be generated when the program runs.
All the Language Environment (LE) CSECTs in your application can be bound with the RTI program modules to enable profiling in order to get a complete picture of overall CPU performance. This includes programs compiled by the IBM COBOL, C/C++ and PL/I compilers as well as COBOL programs optimized by ABO. The time spent in any LE library routines is also collected and reported.
Default
RTIBIND=N | NO
Usage
When RTIBIND=N | NO is specified, ABO optimizes any eligible CSECTs as usual, and does not rebind any of the input program modules with the RTI program modules.
When RTIBIND=I | IN is specified, ABO does not perform any optimizations, but only rebinds all the input program modules with the RTI program modules (that is, rebind the modules specified by the BOPT IN= directive).
When RTIBIND=O | OUT is specified, ABO optimizes any eligible CSECTs as usual, and rebinds any input program modules that have at least one eligible CSECT optimized with the RTI program modules (that is, rebind the modules optimized and placed in the location specified by the BOPT OUT= directive).
When RTIBIND=A | ALL is specified, ABO optimizes any eligible CSECTs as usual, and rebinds these optimized modules plus any input modules that are not optimized, with the RTI program modules (that is, rebind the union of all the modules specified by BOPT IN= and OUT= directives).
New SYSLIB requirement for the JCL used to invoke ABO
When specifying RTIBIND=I | O | A, the JCL used to invoke ABO requires an additional DD name, SYSLIB, to be present (see JCL sample)
//SYSLIB DD DSN=hlqboz.BOZ210.SBOZMOD1,DISP=SHR <- ABO install location
// DD DSN=hlqcee.SCEELKED,DISP=SHR
// DD DSN=hlqcee.SCEELKEX,DISP=SHR
BOZ1426S Link library "SYSLIB" not specified or does not specify a PDS(E).Capturing profiling results during program execution
Before using the RTI Profiler enabled modules, you must allocate a PDS or PDSE dataset in order to hold the profiling results. The RTI Profiler generated report is stored into a member of this dataset. In the following JCL examples, this dataset is named hlq.SYSPROFD.
The following table shows the recommended allocation parameters for hlq.SYSPROFD.
| Data sets | Recommended allocation parameters |
|---|---|
| hlq.SYSPROFD (as a PDS) |
|
| hlq.SYSPROFD (as a PDSE) |
|
In addition, when running the application containing the RTI rebound modules there are two modifications required to your run step JCL in order to collect the profile.
- Add the ABO install location, for example hlqboz.BOZ210.SBOZMOD1, to the existing STEPLIB
- Add the DDNAME SYSPROFD as the location to receive the profiling results
//GO EXEC PGM=pgmname
//STEPLIB DD DSN=hlq.OUT.LOAD.RTI,DISP=SHR <- the RTI rebound modules from ABO
// DD DSN=hlqboz.BOZ210.SBOZMOD1,DISP=SHR <- add ABO install location
//SYSPROFD DD DSN=hlq.SYSPROFD(pgmname),DISP=SHR <- add SYSPROFD DDWhen program execution completes, the profiling results are contained in hlq.SYSPROFD(pgmname).
If SYSPROFD is not added in the execution step, the message RIDATA: OPENING SYSPROFD
FAILED is generated to the job log. Also, the abend code ABEND=S000 U1130
REASON=00000000 is produced.
Understanding the RTI Profiler Results
The output of the RTI Profiler is a text file containing details per compiled or optimized module and CSECT where the program is spending its time while running. There is a high-level summary provided as well as a breakdown of timing samples down to the offsets within each CSECT. For more detailed information, see Run Time Instrumentation report.
In conjunction with the corresponding compiler or ABO listing files for the programs being profiled, the RTI Profiler output can help determine specific parts of your program, down to the machine instruction, where there may be opportunities for improving application CPU performance.
An IBM support or development representative may also request the RTIBIND option be used and an RTI Profile be collected, and its output sent to IBM along with other artifacts (e.g. listing files) from the original compilation or optimization of your programs to aid in performance investigations.
RTI Profiler hardware and software prerequisites
The supported z/OS versions for using the RTI Profiler are z/OS 2.2 and above.
The supported IBM Z systems for using the RTI Profiler enabled modules are zEC12 and later: zEC12, zBC12, z13, z13s, z14, z14 ZR1, z15, and z15 T02.
RTI Profiler capabilities and restrictions
The RTI Profiler is best suited for in-depth CPU profiling of LE enabled batch applications but does not provide other system-level performance metrics such as wait times, I/O performance or DASD usage.
The RTI Profiler can be used on all LE enabled batch applications including IMS batch and batch programs that interact with Db2®. Running non-LE programs that have been rebound with the RTI program modules is not supported and the result is unpredictable.
The RTI Profiler does not work for CICS® applications and is not supported for any application that is part of a non-batch IMS environment.
The RTI Profiler will not work if your z/OS operating system is running on z/VM®. If run on z/VM
guest, the message RISTART: AUTH REQUEST FAILED is output to the job log.
The RTI Profiler does not provide CSECT level details for modules in LPA or that are managed by LLA. Profiling sample information will only be reported at the module level for these cases.
If you require more complete and full featured application profiling, we recommend using a profiling tool such as Application Performance Analyzer for z/OS in ADFz.
- SCAN=Y takes precedence over the RTIBIND option settings. Specifying SCAN=Y disables rebinding with the RTI program modules and optimization of any eligible CSECTs regardless of the RTIBIND option.
- When processing a module originally linked with the AMODE 24 or RMODE 24 option and then processed by ABO with the RTIBIND=I | O | A option, the warning message BOZ1490W is expected. The BOZ1490W message reflects an AMODE/RMODE conflict due to rebinding with the AMODE 31 RTI modules. The message has no impact on the original module execution. The program will still run correctly in the original AMODE 24 or RMODE 24 mode.
- The RTIBIND option is the most convenient way to enable modules for RTI profiling. However, if you require more low-level control of the rebinding process, see Manual RTI rebinding instructions.
- If the program to be profiled was compiled using VS COBOL II or an ABO optimized VS COBOL II
compiled program, an extra step might be needed to rebind the module to replace the bootstrap
routine IGZEBST with the current version from LE. If you do not see any profiling output at the
SYSPROFD location after using RTIBIND and attempting to profile VS COBOL II or an ABO optimized VS
COBOL II compiled program, follow the steps below to replace the IGZEBST routine before using
RTIBIND (or before following the manual rebinding steps) to enable the module for RTI
profiling.
//LKED EXEC PGM=IEWL,PARM=’options’ <- original link options //SYSLIB DD DSN=hlqcee.SCEELKED,DISP=SHR // DD DSN=hlqcee.SCEELKEX,DISP=SHR //LOAD DD DISP=SHR,DSN=&LOAD <- original module that will be linked with new IGZEBST //SYSLMOD DD DISP=SHR,DSN=&SYSLMOD(pgmname) <- output module location //SYSPRINT DD SYSOUT=* //SYSLIN DD * INCLUDE SYSLIB(IGZEBST) <- new bootstrap to include from CEE INCLUDE LOAD(pgmname) <- original member from LOAD to link new parts into REPLACE -IMMED,IGZEBST <- bootstrap member to replace ENTRY pgmname NAME pgmname(R) //*