File Unavailable (Disabled)

Each UDS file has an internal file description table (FDT) entry describing the file (except for the ADT backup file, retention files, and UDS system file). An FDT for a file contains the encoded form produced from the symbolic storage area definition for a file. The UREP repository contains the storage area definitions.

When you or the system catalogs a file, its status is UP, DOWN, DOWN FROM UPDATE, or DOWN-PAGES. The status of the file is recorded in the FDT.

If the status of a file is UP, UDS programs can access it. If the status of a file is DOWN, UDS programs cannot access it. The status of the file is DOWN when one or more of the following conditions exist:

• A program gets a fatal I/O error while writing to the file and while the system is attempting to roll back the program using quick-before-looks.

• A program commits database updates while using the medium recovery strategy.

• A program rolls back or rolls forward during short recovery (the program gets an error message, the system changes the status of the file to DOWN or DOWN PAGES, and the system rolls back the current step of the program, except for updates to the disabled file). If you are using short recovery, the status of the file is marked DOWN and processing continues. This information is passed to the IRU runstream.

• You can use the IRU DOWN command to explicitly set a file to the DOWN state or to the DOWN FROM UPDATE state. If a program attempts to access a file that is in the DOWN state or if a program attempts to update a file that is in the DOWN FROM UPDATE state, the system rolls back the program and issues an error message.

• You can use the IRU DOWN command to explicitly set a page to the DOWN state as well. If a program attempts to access a disabled page, the system rolls back the program and issues an error message.

Recognizing and Correcting Abnormal Conditions

Symptom

A program gets an error message indicating that the program was rolled back because it attempted to access a file or a page in the file that is in the DOWN state.

Analysis

First, determine why the file or page is disabled. Did someone use the IRU command to disable the file or page? Did the system disable the file?

Call IRU and enter the LIST command to check the status of a file. Whenever the file is in a DOWN FROM UPDATE state, it means that IRU was used to place the file in this state.

If the status of the file is DOWN or DOWN-PAGES, you need more information. Do not enable the file or page (using IRU, for example) until you determine why the file or page is down.

If the program incurred a fatal I/O error and received error messages, the system disables the page if possible; otherwise, it disables the file.

If the program did not experience a fatal I/O error, check your administrative save procedures to see whether the file or any of its pages were inadvertently left in a DOWN state during a static dump. Include the IRU LIST command at the end of your save procedure to list the status of all saved files.

If you cannot determine the reason for a status, you can assume that the file had an I/O error when the program rolled back or committed deferred updates.

Corrective Action

If the file or any of its pages were explicitly set DOWN, you can get the file online by calling IRU and performing an UP command. Once the file and all its pages are up, you can reexecute the programs that terminated in error.

If the system disabled the file or a page, use the IRU selective recovery procedure. If the database file is not an audited file, use the reload procedure (see the Integrated

Recovery Utility Operations Guide).

6.2.1.6.File Unavailable (I/O Errors)

If a program gets an I/O error while reading or writing to a database file, the system rolls back the program. If rollback is successful, the database file is left in an UP state.

Two problems can occur during rollback:

• If the database file gets another I/O error while trying to roll back the updates, the system disables the affected page, if possible; otherwise, it disables the file. The system then issues the appropriate message and completes the rollback process.

Recognizing and Correcting Abnormal Conditions

• If the program gets an I/O error while trying to read from the retention file during rollback, the system terminates the program and issues a message that specifies the I/O error and the retention file name. The system also disables all files that have quick-before-looks and after-looks recorded in the retention file, and issues messages indicating the disabled files.

If a program gets an I/O error while writing to the retention file, the system sets the segment to DEAD (and possibly the file to DOWN), and attempts to recover. If the recovery is successful, the thread continues; if not, it attempts a rollback and probably fails. The DEAD segments and DOWN files affect the number of parallel updating threads that can run in UDS and might lead to queuing.

A program might get a fatal I/O error while committing deferred updates to the database file. If this occurs, the system disables the affected page, if possible; otherwise, it disables the file. The system then terminates the thread and issues messages that specify the I/O error and DOWN condition of the file.

Symptom

An active UDS program is rolled back with accompanying error messages indicating that an I/O error occurred while the program was reading from or writing to a database file. The messages also indicate the file name, the I/O error status, and whether the database file error occurred during rollback.

One example of an I/O error message is the DCS 60420 message, as follows:

APP 3 DCS RB 60420 An I/O error 0152 occurred for EXEC FILE UDS$$SRC*DBFILE . at sector 2000 .

The I/O error status is returned by the UDS Control I/O Interface (UDS$IOW). For a description of the I/O error status, see the System Services Programming Reference

Manual.

If the error occurred during rollback, a message indicates that the system disabled either a page or the entire file.

If an I/O error occurred while reading from a retention file, the system terminates the program. The program gets the appropriate messages stating the retention file name and the database files that were disabled because of the error.

The system rolls back a program and issues appropriate messages indicating that an I/O error occurred while writing to the retention file.

A fatal I/O error occurs while writing to a database file to commit deferred updates, and the system terminates the program. The system issues I/O error messages indicating that the file or a page of the file was disabled.

Analysis

Recognizing and Correcting Abnormal Conditions

Corrective Action

If the I/O error occurred while writing to a recoverable database file to roll back or commit deferred updates, use the IRU selective recovery procedure (see the

Integrated Recovery Utility Operations Guide).

If an I/O error occurs while reading from a retention file during rollback processing, use the IRU selective recovery procedure. Selectively recover the disabled database files listed in the error messages. The system automatically deactivates the problem retention file.

If the I/O error occurred while writing to a retention file, you do not have to perform any IRU recovery procedures. Ensure that the rollback was completed successfully; if not you need to use selective recovery.

To correct a retention file, you need to delete and recatalog it. To delete the file, execute IRU using the DOWN command to free the file, specifying the retention file name given in the error message.

Delete and recatalog the file. Ensure that you catalog it with the same security level as the rest of the retention files.

Use the IRU UP command to up the retention file, using the same file name you used on the DOWN command.