File error detection and handling by the server

The server 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 server will automatically try to run a failing operation again, up to a try again limit. When a try again is successful, neither operator nor program action is required.

How the server reports errors

The server 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 might be sent to the program message queue of the program using the file. These messages might 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 server for more information.
The high-level language might 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 server for more information.
A notify, status, diagnostic, or escape message might be sent to the operator message queue (QSYSOPR) or the history message queue (QHST).
Information regarding the error might be saved in the server error log for use by the problem analysis and resolution programs.
An alert message might be sent to an operator at another server in the network.
The normal program flow might be interrupted and control might be transferred to an error-handling subroutine, or other language operations might 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 Recover from file server errors for information about the actions you should take when you receive an error.

Unrecoverable 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 server 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.