Debugger Enhancements

With VisualAge PL/I Version 2.1.8,  when the IBM Distributed Debugger gains control after PL/I detects a severe or critical error, you can optionally fix the error and resume running the program.

This enhancement does not affect debugging capabilities or results in the following cases:

• When an exception or error occurs before a VisualAge PL/I application starts or after it terminates (during run-time initiation or  termination, for instance)
• When executing outside of the VisualAge PL/I run time

Execution errors are reported to VisualAge PL/I in these two ways:

• Windows operating system exceptions
• Software notifications from the VisualAge PL/I run time

Windows operating system exceptions are used for errors that the hardware or the operating system detects. Such errors can occur while applications are running in or outside the VisualAge PL/I run time. Software notifications can occur when validity and consistency checks within the run time detect the error.

To resume running a program (when running outside the VisualAge PL/I) after a hardware or system error, do the following steps:

1. Set the debugger's exception filters to intercept exceptions.
2. Run the code in error.
3. Correct the error if needed, using the debugger.
4. Resume execution using the examine exception and resume debugger option.

To resume running a program following an error,  while the VisualAge PL/I run time is running, the run-time exception handler must gain control.  For software-detected errors, the run-time exception handler gains control by default.  For hardware or system errors that occur when  the debugger's exception filters are set to intercept exceptions, use the run exception debugger option to enable the run-time exception handler.

When the VisualAge PL/I run-time exception handler gains control, the debugger displays a  run-time error message that corresponds to the exception. (The debugger reports these messages as run-time detected errors.)  After you close the message window, the debugger stops at the instruction following the call to the VisualAge PL/I run-time routine that caused the error. To determine the precise location where the application stopped, use either the mixed or assembly view in the debugger.

Errors vary widely. You can ignore some errors and restart an application without making a change.  Other errors can be so serious that the application cannot profitably be resumed.  However, to correct an error for a simple case, you might be able to take the following action:

1. Modify the data in the application to remove the cause of the problem.
2. Set the current instruction of the debugger to an appropriate PL/I statement. The debugger stopped at a point after the problem was detected, so you must restart the debugger at a point before that.
3. Restart the debugger.

In more complicated cases, you can:

1. Modify the data in the application to contain the values that are required to prevent the error.
2. Set the current instruction of the debugger to an appropriate PL/I statement after the statement that caused the error.
3. Restart the application.

In all cases, be aware that after the debugger gains control in an application, the PL/I statements before the point where the debugger stopped might not have completed. Also, after you restart an application following an error, the application might not run the same as it would if no error had occurred.