A typical application that receives an unexpected return code from a callable service usually exits. If an application is written to handle unexpected errors, you need to understand the following information:
Services can fail for a number of reasons: bugs in the system, user code that causes failure return codes, or abend conditions. Depending on when the failure occurs in the service path, the requested function may or may not have been performed. For example, if the application provides an address for a file descriptor that does not exist, the open service (BPX1OPN/BPX4OPN) completes the open processing and then fails on the return path when trying to set the file descriptor. If an EFAULT return code is returned, the user may assume that the file was not opened, even though it was.
If the return value parameter is not in valid storage, a service can complete successfully, yet not return normally to the caller. Because the service cannot set the return value, it abends. It is possible for the C runtime library to convert the return value into a SIGABND or SIGSEGV signal, which can be caught and handled by the user signal action defined in sigaction. You should be aware that functions that abend in this way may have completed their processing. For example, a call to sigaction could modify the state of signal information and then fail on the return to the caller. In this case, the caller should not make any assumptions about the state of the signal environment.