File error detection and handling by the system

The system can detect errors when a file is opened, when a program device is acquired or released, during I/O operations to a file, and when the file is closed. When appropriate, the system will automatically try to run a failing operation again, up to a retry limit. When a retry is successful, neither operator nor program action is required.

How the system reports errors:

The system reports errors that can affect the processing of the program in any or all of the following ways:

• A notify, status, diagnostic, or escape message may be sent to the program message queue of the program using the file. These messages may also appear in the job log, depending on the message logging level that is set for the job. See Messages and message monitors in files by the system for more information.
• The high-level language may return a file status code.
• A major and minor return code is returned in the I/O feedback area for intersystem communications function (ICF), display, and printer files. See Major and minor return codes in files by the system for more information.
• A notify, status, diagnostic, or escape message may be sent to the operator message queue (QSYSOPR) or the history message queue (QHST).
• Information regarding the error may be saved in the system error log for use by the problem analysis and resolution programs.
• An alert message may be sent to an operator at another system in the network.
• The normal program flow may be interrupted and control may be transferred to an error-handling subroutine, or other language operations may occur. For additional information about how to handle run-time errors, see the appropriate book for the high-level language.

Only some of these are significant to a program that is attempting error recovery.

Actions to take when you receive an error:

See Recovering from file system errors for information on the actions you should take when you receive an error.

Nonrecoverable errors:

Not all file errors allow programmed error recovery. Some errors are permanent; that is, the file, device, or program cannot work until you take some corrective action. This might involve resetting the device by varying it off and on again, or correcting an error in the device configuration or the application program. Some messages and return codes inform the user or the application program of conditions that are information rather than errors, such as change in the status of a communications line, or system action taken for an unexpected condition. In many cases, it is possible for the application program to test for an error condition and take some preplanned recovery action which allows the program to continue without intervention from the operator.

For more information:

The CL Programming, SC41-5721-03 book discusses how to use the debug functions to resolve unexpected errors that you encounter in the application programs.

The chapter on handling problems in the Basic System Operation, Administration, and Problem Handling, SC41-5206-04 book describes the programs that are available for analyzing and reporting system errors and hardware failures.