This article explains the various reasons why an RTS 115 Unexpected Signal (Signal n) might be generated.
Problem:
If the runtime system is not expecting the signal at this time, or never expects to catch the signal, then the default runtime system signal handler will produce the runtime error message (where n is the signal number):
Execution error : file 'name'
error code: 115, pc=p, call=c, seg=s
115 Unexpected Signal (Signal n)
Resolution:
The COBOL Runtime System posts signals handlers for various signals, including all signals whose Operating System default action is to cause the process to terminate. This allows us to clean up before the process terminates and allows us to achieve other COBOL functionality.
When a signal is generated, it is processed using the list of prioritized posted signal handlers. If the Operating System default action is to cause the process to exit, then there will be a default Runtime System signal handler for it.
If the signal number identifier in the error message is 4 (SIGILL) then it means that the Operating System was trying to execute some invalid machine instructions. This usually occurs when an invalid or uninitialized procedure pointer is undirected through. This can also occur when generated machine code becomes corrupted. The invalid pointer or generated machine code corruption is frequently cause by memory corruption elsewhere within the application.
The cause is normally that some user or third party code has caused the signal (eg. by raising the signal or calling some Operating System routine that raises a signal) without first posting a signal handler using cobpostsighandler().
If the cause is in your (user) code then a signal handler should be written or posted using cobpostsighandler(). If the cause appears to be due to some third party code then try re-running the application with the signal regime run-time tunable set as follows:
set signal regime(n) = 1
This will prevent the run time system from over ridding any previously posted (third party) signal handlers for signal n.
The following third parties are known to cause such errors:
IBM DCE - uses signals such as SIGUSR2 and SIGVTALRM for thread switching on some platforms.
TXSERIES CICS - tries to override our signal handlers with their own.
For more details see the Handling Protection Violation Errors in the Program Development Manual Chapter 5.
