Skip to main content

This article explains how to analyze intermittent Signal 115 errors when using Oracle.

Problem:

How do you analyze intermittent unexpected Signal 115 errors when using Oracle?

Resolution:

Analysis of the core dump using dbx stack trace will indicate where the error is occuring. The steps taken to analyze the RTS 115 error using a core dump are as follows:

The default action of the COBOL RTS is to catch the signal and report a 115 error to highlight an unexpected signal. When the core_on_error=2 runtime tunable is set in cob.cfg file, then the RTS does not catch the signal and a core file is produced instead.

Create a cob.cfg file and enter:

set core_on_error=2

export COBCONFIG=$Home/cob.cfg

The core file is of no use without the original executable and all the shared objects it has loaded, so it must be analyzed on the same system and with the same environment variables under which the core file was produced. For example, if the application is compiled to gnts, and rtsora is used to execute the gnts,enter:

dbx 'which rtsora32' core.123

If the application is a linked executable and the core file is named core.123 enter:

dbx /mytestdir/myexename core.123

Note: dbx stack trace is obtained from the "where" command.

dbx 'which rtsora32' core.123

where

fd

map

thread

thread info

thread current 1; where

thread current 2; where

quit

Note: COBDIR, PATH and LIBPATH (for AIX) or SHLIB_PATH(HP/UX) or LD_LIBRARY_PATH(SUN, LINUX) will need to be setup the same as when the original application was run (otherwise dbx won't be able to find the executable or the shared objects that were loaded when the core dump was produced).
Note: The initial thread command will list two or more threads. If more than two threads are listed then thread current ; where will need repeating for each thread.
Old KB# 13995
Terms & ConditionsAccessibility statement