Modifying dynamic configuration data of SF and SM pubsets

"Dynamic configuration data" comprises configurations of pubsets (volumes of SF and SM pubsets and volume sets of SM pubsets), as well as usage restrictions and the cache configuration.

The current pubset configuration of the system can be displayed using the SHOW-PUBSET-PROCESSING command.

The command SHOW-DEVICE-CONFIGURATION UNIT=*PUBSET-DEVICES(...) is used to output information on a selection of disks belonging to the pubset.

Modify the configuration of a pubset

The configuration of a pubset can be modified using the MODIFY-PUBSET-PROCESSING command. The following options are available:

• Individual disks can be added to or removed from an SF pubset.

• Individual volume sets can be added to or removed from an SM pubset.

• Individual disks can be added to or removed from a volume set which is the component of an SM pubset.

Pubres and Volres cannot be removed from the SF pubset/volume set.

An empty volume which is suitable for the pubset or volume set can be added with SIR, which is used for pubset generation.

Notes on volume set reconfiguration

• A volume set must be defined with the MODIFY-PUBSET-DEFINITION-FILE (EDIT-PUBSET-DEFINITION-FILE) command before it can be activated for an SM pubset.

• Before a volume set can be deactivated, it must be cleared of all files and locked against primary allocation (see "Restricting usage to remove disks and volume sets").
  A defective volume set is an exception to this rule and deactivation can be forced, which causes all the files it contains to be lost. Because of this, a list of all files on the defective volume set is created when it is deactivated and can be used directly as an input file to the HSMS subsystem for restoration. The list is stored in the file
  $TSOS.SYS.PUBSET.DEFECT.<volume-set-id>.<date.time>.
  The defective state of a volume set is either detected by the system itself, e.g. when it is no longer possible to access the metadata on a volume set, or it can be set with the MODIFY-PUBSET-RESTRICTIONS command.

Notes on disk reconfiguration

• When adding an empty disk, the disk properties must be compatible to those of the volume set or SF pubset.

• In the case of disk removal, a check is first made to ensure that the disk is empty. Then the disk data structures are cleaned up and the access rights released.

• Disks of a pubset can be attached and detached with the ATTACH-/DETACH-DEVICE UNIT=*PUBSET-DEVICES(...) commands. Since the names of the corresponding disks are managed in the SVL of the system disk, these must have been entered in MRSCAT . The entry is made each time the pubset is imported or exported, when changing the makeup of the pubset (MODIFY-PUBSET-PROCESSING), or explicitly with the ADD-, EDIT- or MODIFY-MASTER-CATALOG-ENTRY command.

  As many disks as possible are always attached. When mirroring with DRV, both disks are attached. When mirroring in a disk storage system controller, only the standard disks are attached. If the mirror disks are to be attached, then the mirror disk of the system disk (Pubres) must be specified in the PUBSET operand.

Checking the homogeneity in the case of pubset extension

When pubsets are extended using the MODIFY-PUBSET-PROCESSING command, a homogeneity check for mirroring is performed when the CHECK-PUBSET-MIRRORS=*YES operand is specified: If a volume which has different mirroring properties from the volumes which have already been processed is detected in the course of pubset extension, the answerable message DMS1369 is output to SYSOUT.

Depending on the caller’s answer, one of the following procedures is selected:

• Pubset extension is aborted

• Despite inhomogeneity being detected on the pubset volume which is being processed, pubset extension is continued. The message DMS136B is issued on the console for every further volume with different mirroring properties.

The subsystem SHC-OSD must be available for the homogeneity check.

The CHECK-PUBSET-MIRRORS command also enables you to check the homogeneity of pubset mirroring before the pubset configuration is changed dynamically.

When a pubset is placed in service, the homogeneity check can be requested using the operand of the same name in the IMPORT-PUBSET command.

Criteria for the homogeneity of pubset mirroring

A pubset is homogeneous with regard to local mirroring when the following conditions are satisfied:

• The same number of mirror units is assigned to all volumes of the pubset.

• All mirror units of the pubset are in the same operating state. By and large only the operating states ESTABLISHED and SPLIT are of importance here; the ESTABLISHING and SPLITTING states only occur temporarily as intermediate states.

• If remote mirror units are also being used, either all mirror units which are assigned to the pubsets are located in the local or in the remote disk storage system, or there is a complete set of mirror units in both the local and the remote disk storage system.

The pubset is homogeneous with regard to remote mirroring when the following conditions are satisfied:

• The same number of mirror units is assigned to all volumes of the pubset in the remote disk storage system.

• All remote mirror units are in the same state, ACTIVE or IN-HOLD.

• All remote mirror units are operated in the same mode (synchronous, semi-synchronous or adaptive).

• All remote mirror units are located in the same remote disk storage system.

Restricting usage to remove disks and volume sets

An object cannot be removed from the pubset configuration if it contains any data. The MODIFY-PUBSET-RESTRICTIONS command is an important tool for fulfilling this requirement. Systems support can use it to assign or release access and allocation restrictions.

• Allocation restrictions

  They can be granted for volumes or volume sets. Volumes can thereby be completely locked against allocation or only cleared for physical allocation. Volume sets can be locked against primary allocation or only cleared for physical allocation, where physical allocation means direct specification of the volume set ID.

• Access locks

  These exist exclusively for volume sets. When a lock is set, access to data in the files on the volume set is reserved exclusively for systems support. A volume set can simultaneously be completely closed, i.e. all access to the metadata on it is forbidden. This access lock is to be recommended if an error is predicted for the volume set, e.g. caused by an I/O request failure. The volume set is subsequently seen as defective if the access lock cannot be revoked.

  A lock to create files is not possible for the control volume set as this would cause undesired impedance of system functions.

Setting the volume-oriented restrictions reduces the number of freely available volumes and the amount of freely available space. It is not allowed if a severe storage bottleneck already exists (saturation level 4 exceeded) or would be caused by setting the restriction.