File Unavailable (Security Violation)

UDS catalogs and assigns its system files during installation. Therefore, for systems without Security Option 3, system files must have the same security level as the installation run. Ensure that the installation run and all subsequent UDS users have the same security level.

System files remain assigned to the UDS common bank until a system failure occurs. Following a system failure, the IRU short recovery procedure must be performed so that UDS reassigns its system files. Users cannot access the application group until short recovery is run. UDS recatalogs the system files if the Exec cannot recover the files (for example, because of a disk failure). These conditions apply to both systems without Security Option 3 and to those that have common bank protection turned on.

For systems that have common bank protection turned on, the system files have the security level of the owner of the files. The owner is the user-id given as the UDS subsystem user-id during installation.

UDS Control is a protected subsystem. This means that when UDS Control assigns a file, the security attributes of the protected subsystem determine whether or not the file can be assigned. In short, the UDS subsystem must be able to assign files.

The owner of the application group file application-group-qualifier*UDSC$PFGSDEF is the UDS subsystem user-id (for the default application group, for example, the owner of file UDS$$SRC*UDSC$PFGSDEF). The user-id was created when UDS Control was installed.

The UDS Control subsystem must be able to read and write the retention files. The clearance level of the retention files must therefore be the same as the clearance level of the UDS Control protected subsystem. Further, when UDS Control catalogs the retention files, it catalogs them with the clearance level and compartment set of the UDS Control protected subsystem. In general, the UDS Control subsystem user-id must be able to assign the files, which means that both mandatory and discretionary security checking must allow access to the files.

For further information on security user-ids required for UDS products, see the

Universal Data System Planning and Installation Overview.

Assume that the system failed and you initiated IRU short recovery. If the Exec is unsuccessful in recovering queue items, IRU accesses the audit trail to recover the queue items. During initial boot, the system uses the highest level of security available (clearance level 63) to catalog the audit trail file and ACI file. Therefore, any runstream calling IRU must have the same security level. If not, IRU short recovery cannot assign the audit trail file or ACI file, short recovery fails, and the application group becomes unavailable.

You can use the REFRESH runstream to automatically initiate short recovery after a system failure. If you use the runstream, the security level of the runstream is assigned to recataloged UDS system files. If you do not use the runstream, the security level of the user program is assigned to recataloged UDS system files.

Recognizing and Correcting Abnormal Conditions

Ensure that the security level of the UDS system files is low enough so that all database users can access the system files.

Symptoms

One of the following symptoms occurs:

• A UDS program gets an error and rolls back if the system cannot assign a required database file. The program gets an error message indicating which file cannot be assigned. If the accompanying facility status has a value of 10 (that is, bit 3 is set), the program has incurred a security violation.

• Following a system failure, IRU returns an error indicating that the system cannot assign either the audit trail file or ACI file. The error message also indicates that the status word has a value of 10. The program that gets the error is either the first program triggering the REFRESH element, or if the REFRESH element is not set up, the program that explicitly invokes IRU short recovery.

• Following a system failure, if the database files are reassigned with a security level greater than originally cataloged, IRU cannot roll back updates from the retention files to the databases. When a program tries to write to the database files, it gets an I/O 20 error for each database file that has updates recorded in the retention files. Even though IRU messages state that short recovery is successful, the system disables each database file that encountered the error and issues the appropriate message.

• A UDS program gets an error and the UDS session terminates because the system cannot write to a retention file. The error messages indicate the name of the file causing the error and display an I/O error status of 20.

Analysis

An I/O 20 error or file assignment status of 10 indicates a file security conflict.

Corrective Action

If short recovery is not successful because the audit trail or ACI file cannot be assigned (status=0) when invoking the REFRESH element, you can take one of two corrective actions (the first approach is generally preferred):

• Use TeamQuest SIMAN to lower the security level of the audit trail file and ACI file to the security level of all other UDS users (that is, the security level of all other UDS database and system files).

• Follow these steps:

1. Before calling IRU, use the COMUS CLOD processor to put yourself into privileged mode; this bypasses file security so that you can assign the audit trail file and ACI file. This also ensures that all other system files are assigned at the proper security level and enables IRU to assign the audit trail file and ACI file, which have a security level of 63.

2. If you invoke IRU manually from a separate runstream, ensure that your security level is that of all other UDS system and database files.

Recognizing and Correcting Abnormal Conditions

3. Remove the REFRESH element from the app-name*SYM$ file for the application group and invoke the IRU short recovery procedure.

If the retention file is getting I/O 20 errors, a runstream has assigned the files to the UDS common banks and used a security level that is too high. Follow these steps to free the files and assign them to a security level equal to all other UDS database files:

1. Manually abort the application group so that it is inaccessible. Execute the UDS supervisor program (SUDS) and use an II command to abort the application group and set the application group to a pending state. For more information about SUDS, see Section 8.

2. Ensure that you freed all retention files from the UDS common bank before running IRU short recovery. You can use the SUDS FF command to free each file. 3. Using the TeamQuest SIMAN processor, interrogate file security levels to ensure

that they are cataloged at the proper security level. If they are not, set them to the same level as all database files.

4. Use IRU short recovery. When calling IRU, remember to use the same security level as all other database files