A storage class represents a specific combination of values for the file attributes AVAIL-ABILITY, PERFORMANCE, USAGE, DISK-WRITE, FILE- PREFORMAT and WORK-FILE. In addition, systems support can link storage classes to a predefined list of volume sets to be given priority (but not to be considered exclusively) by the system during storage space allocation for a file. The use of storage classes can be restricted by assigning guards profiles.
Information about the storage classes created by systems support and available to users as well as their characteristics (with the exception of the associated list of volume sets, if any) is supplied by the SHOW-STORAGE-CLASS command. The STORAGE-CLASS operand of the commands CREATE-FILE and MODIFY- FILE-ATTRIBUTES or the STOCLAS operand of the macros FILE and CATAL can be used to inform the system of the requirements for a file by assigning it a suitable storage class (instead of specifying file attributes directly).
In comparison with direct attribute specification, storage classes enable a convenient user interface to be provided which is tailored to the services offered by a specific SM pubset. Using storage classes rather than direct attribute specification permits JCL procedures to be kept concise and easy to understand.
Storage classes are defined on a pubset-specific basis.
To make use of the benefits offered by a particular SM pubset, users require information about available storage classes and their meaning; knowledge of the physical configuration implemented by the services is not required.
Modifying the service requirements for a file
The user can make allowance for changing requirements for a file by assigning it a new storage class. This implicitly assigns the file attributes specified in the storage class definition to the file (with the exception of the preformat). As a result of changed requirements for a file, the volume set on which the file is currently residing may no longer be suitable because it does not (fully) comply with the new file attributes or is not included in the list of volume sets associated with the new storage class.
Immediate relocation of the file to another volume set takes place when the new file attributes are not compatible with the file’s current storage location. Immediate relocation can also take place when the volume set to which the file belongs does not belong to the volume set list of the new storage class. Where immediate relocation of the file is not required, the changed requirements will not take effect until the next recall of the file from a background level to the processing level. This could take place, for instance, as a result of pubset reorganization initiated by systems support. The user can modify individual attributes for a
file assigned to a storage class via direct attribute specification. In doing so he/she can overrule the previous storage class assignment. This fact must be taken into account, in particular if the storage class is linked with a volume set list.
Modifying the characteristics of a storage class
Modifications of volume set lists automatically take effect even for existing files, since they will be taken into account by subsequent recalls. Modifications of the combination of attributes represented by a storage class, on the other hand, do not automatically apply to existing files; this can be remedied by systems support or the user explicitly updating the storage class (command MODIFY-FILE-ATTRIBUTES (STORAGE-CLASS=*UPDATE)).