The subroutines in this category allow your application to modify the error handling characteristics of the graPHIGS API system. By default, the error handler provided by the graPHIGS API is given control when an error is detected. However, the application can provide an alternative error handler which supersedes the default and receives control when an error is detected.
If desired, the Set Error Handling Mode (GPEMO) subroutine can be used to set error handling 1=OFF When error handling is 1=OFF , processing continues until an ABEND condition is reached. Generally, error handling should remain 2=ON in a program development environment. Error handling is 2=ON by default.
See The graPHIGS Programming Interface: Understanding Concepts for details on error handlers and their operation.
See The graPHIGS Programming Interface: Writing Applications for information on the techniques used to code application error handlers in specific languages.
See The graPHIGS Programming Interface: Messages and Codes for information on specific error conditions and system responses - severity levels, etc.
| GPEHND (error-handler) |
Purpose
Use GPEHND to specify the address of an application-defined first-level error handling routine.
The graPHIGS API gives control to this routine when an error is detected. If an application error handler is not defined, the graPHIGS API uses the default, which logs an error in the file specified by the first parameter of the Open graPHIGS (GPOPPH) subroutine. A first-level error handler can only invoke Inquiry subroutines and the Error Logging (GPELOG) subroutine.
The application error handler receives six parameters, when invoked.
Parameters
The default error handler can be reset by specifying an error handler address of a fullword binary zero.
A user supplied error handler receives the parameter list shown above only if the application is using the non-reentrant interface. If it is using the reentrant interface, the error handler receives the Application Anchor Block (AAB) as its first parameter, followed by the other parameters. If the application is using the System Programmer's Interface (SPI), it receives the following data: the AAB; a Request Control Parameter code (RCP), which it should ignore and must not corrupt (this code provides the only way to return to the program once error processing is completed[default] and the remaining parameters. The error handler has one special consideration. It is possible for an application to mix SPI and re-entrant subroutines. If it does, the error handler receives varying length parameter lists. The type of list passed by the application depends on the type of the current graPHIGS API subroutine. The only way the error handler can differentiate between interfaces is by checking the number of parameters and by searching for the End of List marker. See The graPHIGS Programming Interface: Writing Applications
In effect, mixing the two types of interface subroutines is practical only if the language in which the error handler is written allows the number of parameters to be determined.
Error Codes
None
Related Subroutines
RCP code
201337857 (X'0C002C01')