If a volume in an SF pubset or a volume set fails or is partially defective, this pubset or volume set can no longer be worked with continuously.
The error can only be eliminated by reinitializing the volume concerned. This generally means the loss of all data on the volume. The pubset can only be activated again after it has been completely reconstructed from the backup.
It is therefore necessary to detect such volume areas in good time to enable them to be excluded from future storage space requests. After the volume error is detected, suitable error elimination measures can be initiated.
Detecting hardware errors with DMS
With shared volumes (pubsets), the DMS checking mechanism ensures that permanent volume errors which occur during access by DMS are made known to the allocation components and excluded from further storage space assignments. This ensures that these registered volume areas are not used to fulfill any future requests for storage space and that defective volume areas do not spread to other files.
The information on defective volume areas is stored in the pubset-specific defect garbage file which is generated by the system.
The first time a volume error is registered within a pubset, the file is generated on this pubset under the following path name (dependent on the pubset type):
for SF pubsets: :<catid>:$TSOS.SYSDAT.DEFECT.GARBAGE.<catid#>
for SM pubsets: :<catid>:$TSOS.SYSDAT.DEFECT.GARBAGE.<volume-set-id#>
<volume-set-id#> designates the catalog ID of the volume set containing the file. If the catalog ID of the SF pubset or volume set is shorter than four characters, the <catid#> and <volume-set-id#> variables are padded to four characters.
The extent list of this file only consists of the extents which the reported defective blocks of the pubset encompass. This means that these defective blocks are allocated twice for the lifetime of the file, once in the file itself and once in the defect garbage file.
The defect garbage file may only be processed by the appropriate system components and all accesses are rejected. A file password is assigned and the file protection attribute is set to ACCESS=READ to prevent access.
The defect garbage file is set to backup level E, i.e. it is not backed up by ARCHIVE or HSMS. This prevents inconsistent conditions from occurring.
As with other files, the defect garbage file extent list has a limited capacity. It can only record approximately 140 to 310 extents, depending on volume distribution, which corresponds to the maximum number of defective blocks per pubset. Message DMS060C is output to the console if this capacity is exceeded. If this occurs, it is imperative that the pubset is reorganized as soon as possible to eliminate the volume errors (e.g. with VOLIN).
An existing defect garbage file can only be deleted via the IMPORT-PUBSET processing of the pubset concerned. During IMPORT-PUBSET processing, a check is made to see whether a defect garbage file exists and, if it does, whether blocks have already been repaired. If they have been repaired, these blocks can be reintegrated into the normal storage space assignment process. This is done explicitly in the IMPORT-PUBSET processing via an F5 reconstruction. The defect garbage file is deleted as soon as no (registered) defective blocks exist for this pubset.
The defect garbage file may, under no circumstances, be deleted manually. This must be done exclusively by the system mechanisms. Otherwise, this would result in data loss and the destruction of the F5 labels!
Double allocations between the defect garbage file and other files may occur with the F5 reconstruction of a pubset during the import process (messages DMS0461 and DMS0462). These messages are not, however, to be taken as an indication of system errors or inconsistencies in the F5 area, they only indicate defective volume areas in the allocation area of the reported files.
Error message DMS0608 may also appear on the console during pubset operation. This reports just one defective block. The following error occurs when an attempt is made to enter it in the defect garbage file: a file exists with a name structure belonging to a defect garbage file (see above) but its internal structure (catalog attributes) deviates from that of a normal defect garbage file. Message DMS0608 must be answered. An attempt can thereby be made to use the existing file as a defect garbage file. If this does not succeed, the function can be canceled, i.e. either the defective block has not been entered or the system generates a new defect garbage file and implicitly deletes the existing one.
Assigning a manual allocation lock
Allocation on defective volumes can be forbidden on a volume-specific basis for SF and SM pubsets as well as on a volume-set-specific basis for SM pubsets (see the MODIFY-PUBSET-RESTRICTIONS command).
Even when SM pubsets are imported, it is possible to prevent the allocation of volume sets with defective volumes. In this case, the volume sets can be set to the state “defect” or “in hold” (see the IMPORT-PUBSET command, operand DEFECT-VOLUME-SET or IN-HOLD-VOLUME-SET).