Created On: 24 August 2010
Problem:
RTS 114 error had occurred when a CICS application overrun a data block returned by an EXEC CICS RECEIVE ... SET(...) command.
Resolution:
When the RTS error happens, it may require some level tracing such as CAS files, CTF traces to correct the offending application.
Diagnostics required:
CAS: Auxiliary trace, Storage Control and Task Control trace flags on.
CTF: Memory, PGM, PGMLOAD, PGMSEARCH
Memory strategy: 0x80000001 or 0x80000003
The memory strategy will cause an RTS error to be thrown if corruption is detected.
Because memory integrity is checked on every allocation and free the CTF trace will allow you to identify the window in which the corruption occurred.
Start in the CTF trace for the faulting process.
Locate the 249 and then search backwards to find a memory event (13-16).
From that point, again work backwards until you find a program entry (6) which does not have a corresponding exit (7).
The address reported in the 249 event is the address of the runtime’s header for a memory allocation.
The RTS control header for the memory types for which corruption is being reported are 20 bytes in length so add that to the (249) reported address and search backwards for that value on a memory allocation (13) event. e.g. reported 0x015be954 -> 0x015be968.
This will probably be a sandwiched between an API entry/exit pair (events 56 and 57) with 28 as the first parameter listed after the colon. This represents a call to CBL_ALLOC_MEM showing the size of storage requested as the second parameter.
The address output on the 57 event will be what is reported in the Enterprise Server auxiliary trace.
N.B. The CTF is chip agnostic whereas ES trace is not. This means that for Intel platforms you need to reverse the address from the CTF log to use for the search string in the ES trace.
Format the auxiliary trace specifying the process ID using the -p option.
Search the formatted auxiliary trace for an allocation (trace entry ID "nn 8302nn") which reports the target address in the Field--A column.
Matching the date-stamp in the auxiliary trace with that of the CTF event should help identify the correct entry.
The annotation on the left will indicate the memory type.
This may be easily identifiable - e.g. commarea or more generic - local-user type memory is allocated for RECEIVE ... SET(), READ ... SET() etc.
Diagnostics required:
CAS: Auxiliary trace, Storage Control and Task Control trace flags on.
CTF: Memory, PGM, PGMLOAD, PGMSEARCH
Memory strategy: 0x80000001 or 0x80000003
The memory strategy will cause an RTS error to be thrown if corruption is detected.
Because memory integrity is checked on every allocation and free the CTF trace will allow you to identify the window in which the corruption occurred.
Start in the CTF trace for the faulting process.
Locate the 249 and then search backwards to find a memory event (13-16).
From that point, again work backwards until you find a program entry (6) which does not have a corresponding exit (7).
The address reported in the 249 event is the address of the runtime’s header for a memory allocation.
The RTS control header for the memory types for which corruption is being reported are 20 bytes in length so add that to the (249) reported address and search backwards for that value on a memory allocation (13) event. e.g. reported 0x015be954 -> 0x015be968.
This will probably be a sandwiched between an API entry/exit pair (events 56 and 57) with 28 as the first parameter listed after the colon. This represents a call to CBL_ALLOC_MEM showing the size of storage requested as the second parameter.
The address output on the 57 event will be what is reported in the Enterprise Server auxiliary trace.
N.B. The CTF is chip agnostic whereas ES trace is not. This means that for Intel platforms you need to reverse the address from the CTF log to use for the search string in the ES trace.
Format the auxiliary trace specifying the process ID using the -p option.
Search the formatted auxiliary trace for an allocation (trace entry ID "nn 8302nn") which reports the target address in the Field--A column.
Matching the date-stamp in the auxiliary trace with that of the CTF event should help identify the correct entry.
The annotation on the left will indicate the memory type.
This may be easily identifiable - e.g. commarea or more generic - local-user type memory is allocated for RECEIVE ... SET(), READ ... SET() etc.
Incident #2470178
Old KB# 31645
#MFDS
#EnterpriseDeveloper
#RTS
#OVERRUN
#memoryviolation
