Setting up an individual standby pubset

Procedure:

1. Attach the disks which are required for mirroring (ATTACH-DEVICE command).

2. Assign a mirror disk to each disk (unit) of the pubset (START-CLONE-SESSION command).
   As a result the data is copied from the pubset to the mirror disks and then kept synchronous.

3. Create a synchronization point.

   • For home pubsets this means:
     Write back the host buffer for the home pubset and stop or terminate applications on the home pubset (DAB write caches are not permitted on the home pubset and consequently do not need to be considered).

   • One of the following actions must be performed for data pubsets:

     • Close all files, terminate DAB write caches, and write back the host buffers of other applications. This can be achieved by briefly terminating all applications and exporting the pubset.

     • The applications define a synchronization point themselves without exporting the pubset (see the “SHC-OSD” manual [48]).

4. Split the disks and mirror disks (ACTIVATE-CLONE command)

   • If a home pubset consists of more than one disk, all the disks must be split simultaneously in order to ensure that the data remains consistent and can be reconstructed. As far as possible, metadata should be located on only one logical disk.

   • If a data pubset consists of more than one disk, the metadata (file, user, GUARDS catalogs, etc.) should, as far as possible, be located on only one logical disk. All the disks must be split simultaneously at the split time in order to guarantee data consistency and permit reconstruction.

5. Detach the mirror disks (DETACH-DEVICE command).
   This generates the standby pubset which can be used if a fault occurs.

6. Reattach the disks of the standby pubset (ATTACH-DEVICE command).

7. Initiate synchronization with the pubset again so that the data of the standby pubset is updated (RESTART-CLONE-SESSION command).

8. Continue with step 3.

Example with local mirroring using clones

Setting up alternating standby pubsets

When just one standby pubset is used, periods exist in which no standby pubset is available (during updating and renewed splitting). For critical applications it is therefore advisable to use two alternating standby pubsets which are available and updated on an alternating basis.

Procedure:

1. Attach the disks which are required for mirroring (ATTACH-DEVICE command).

2. Assign a mirror disk (clone unit) to each disk (unit) of the pubset twice (START-CLONE-SESSION command).
   As a result the data is copied from the pubset to the mirror disks and then kept synchronous.

3. Create a synchronization point for the first standby pubset.

   • For home pubsets this means:
     Write back the host buffer for the home pubset and stop or terminate applications on the home pubset (DAB write caches are not permitted on the home pubset and consequently do not need to be considered).

   • One of the following actions must be performed for data pubsets:

     • Close all files, terminate DAB write caches, and write back the host buffers of other applications. This can be achieved by briefly terminating all applications and exporting the pubset.

     • The applications define a synchronization point themselves without exporting the pubset (see the “SHC-OSD” manual [48]).

4. Split the disks and mirror disks for the first standby pubset (ACTIVATE-CLONE-UNIT command)

   • If a home pubset consists of more than one disk, all the disks must be split simultaneously in order to ensure that the data remains consistent and can be reconstructed. As far as possible, metadata should be located on only one logical disk.

   • If a data pubset consists of more than one disk, the metadata (file, user, guards catalogs, etc.) should, as far as possible, be located on only one logical disk. All the disks must be split simultaneously at the split time in order to guarantee data consistency and permit reconstruction.

5. Detach the mirror disks for the first standby pubset (DETACH-DEVICE command).This generates the first standby pubset, which can be used if a fault occurs.

6. Create a synchronization point for the second standby pubset.

7. Split the disks and mirror disks for the second standby pubset (ACTIVATE-CLONE-UNIT command)

8. Detach the mirror disks for the second standby pubset (DETACH-DEVICE command). As a result the second standby pubset is generated, and this has more up-to-date data than the first one and can be used if a fault occurs.

9. Reattach the disks of the first standby pubset (ATTACH-DEVICE command).

10. Initiate synchronization of the first pubset with the pubset again so that the data of the standby pubset is updated (RESTART-CLONE-SESSION command).

11. Continue with step 3 for the first standby pubset.

12. If the first standby pubset is split again, attach the disks of the second one again (ATTACH-DEVICE command).

13. Initiate synchronization of the second standby pubset with the pubset again (RESTART-CLONE-SESSION command).

14. Continue with step 6 for the second standby pubset.

Example with local mirroring using clones

Generating a home pubset for the standby system

In a high-availability network, a separate home pubset is required for the use of the standby system. This home pubset, which has the character of a standby pubset but has its own catalog ID, can also be created using the disk storage systems’ local replication functions.

The following example illustrates how a home pubset with a new catalog ID is generated. The starting situation is as follows:

• The MR pubset contains a loadable BS2000 of the current version.

• The MR pubset consists of three disks (units) with the mnemonic device names 5070, 5071 and 5072.

• The active BS2000 system was started from the MR pubset.

• Three further mirror disks are available for mirroring (5073, 5074 and 5075).

Procedure

1. Generate copies for the MR pubset (clone units 5073, 5074 and 5075):

   /START-CLONE-SESSION UNIT=*BY-PUBSET(PUBSET=MR),
CLONE-UNIT=(5073,5074,5075),DIFFERENTIAL=YES,COPY-COMPLETE-DATA=YES

2. Create a synchronization point. This means:
   Write back the host buffer for the home pubset and stop or terminate applications on the home pubset (DAB write caches are not permitted on the home pubset and consequently do not need to be considered).

3. Split or activate copies, at the same time generating the pubset with the new catalog ID WG.

   /ACTIVATE-CLONE UNIT=*BY-PUBSET(PUBSET=MR,NEW-PUBSET=WG,
HOLD-IO=*UNTIL-ACTIVATED)

4. Call PVSREN and use the PVSREN statements to rename as required:

   /PVSREN
   . . .
   //RENAME-PUBSET-OR-VOLUME-SET NAME=MR,NEW-NAME=WG,
     SYSID=173,MODE=*COMPLETE-SHC-RENAME
   %  PVR0201 CHANGE DEFAULT CATALOG ID ENTRY 'TT' TO DEFAULT CATALOG ID
   ENTRY 'WG' IN USER CATALOG OF HOME PUBSET ? (Y=YES; N=NO)?N
   %  PVR0202 CHANGE DEFAULT CATALOG ID ENTRY 'TT' TO DEFAULT CATALOG ID
   ENTRY 'WG' IN USER CATALOG OF NEW PUBSET ? (Y=YES; N=NO)?Y
   %  PVR0206 CHANGE CATID ENTRY 'TT' IN STANDARD IMON SCI OF HOME PUBSET TO
   CATID 'WG' ? (Y=YES; N=NO)?N
   %  PVR0203 READY PUBSET IN THIS BS2000 SYSTEM ? (Y=YES; N=NO)?N
   //END
   %  PVR0145 PVSREN TERMINATED NORMALLY

For details on PVSREN see on section "Managing SYSEAM storage space on pubsets" or the complete description in the “Utility Routines” manual [15].

The current passwords of important user IDs (in particular TSOS) should be retained since if the new home pubset is subsequently used on the standby system, the user catalog and consequently also the user passwords are “reset”.

In addition, it should be noted that within procedures and programs, file accesses with an explicit specification of the catalog ID should be avoided since these can result in errors when the new pubset is used.