Synchronization point for replications

Before a local or remote clone pair (QuickOPC), or snap pair (SnapOPC+) is created, or before activating a local (EC) or remote (REC) mirror, a consistent synchronization point must be created for the data.

For this purpose the following actions must be performed:

• suspend or terminate applications

• close all files or

• export the pubset
  Only with an exported pubset is it ensured that all data buffered using DAB are written back from the cache (database etc.).

If you do not export the pubset, note the following, see the “Commands” manuals [1]:

• Write caching using DAB at server level must be terminated:

  • PFA caching: /STOP-PUBSET-CACHING

  • ADM-PFA caching: /STOP-DAB-CACHING

• If the pubset consists of more than one original unit, input and output processes should be stopped during splitting:

  • Command /START-SNAP-SESSION, /RESTORE-FROM-SNAP for SnapOPC+

  • Command /START-CLONE-SESSION for QuickOPC clones resp. /ACTIVATE-CLONE, /RESTART-CLONE-SESSION for EC clones, /RESTORE-FROM-CLONE-SESSION for clones in general
  • Command/HOLD-REMOTE-COPY, /RESUME-REMOTE-COPY for remote copy pairs

    each with operand UNIT=*BY-PUBSET and HOLD-IO=*UNTIL-ACTIVATED.

• During import, the split pubset on the snap/clone units or Remote-Copy targets behaves as if the last export procedure had not been executed. Consequently either the message DMS038C must be answered with Y or the SESSION-CHECK-MSG=*NO operand must be specified in /IMPORT-PUBSET. The F5 labels on the disks are reconstructed from the catalog.

  Files on the split pubset are in the same status as on the original pubset at the time splitting took place; they may possibly not have been closed. In this case the /REPAIR-DISK-FILES command is required if this is not executed automatically by the application (same effect as restart after system failure).

If the split pubsets are processed in the same BS2000 session as the originals, they must be renamed. Note the following:

• The snap/clone units or Remote-Copy targets must be (generated and) attached.

  • Command/START-SNAP-SESSION, /RESTORE-FROM-SNAP for SnapOPC+
  • Command/START-CLONE-SESSION for QuickOPC clones bzw. /ACTIVATE-CLONE, /RESTART-CLONE-SESSION for EC clones, /RESTORE-FROM-CLONE-SESSION for clones in general
  • Command/HOLD-REMOTE-COPY, /RESUME-REMOTE-COPY for remote copy pairsSF pubsets can be renamed directly with the following commands, each with the NEW-PUBSET=<new-catid> operand. The new pubset ID can also be shorter than the old pubset ID.
• IMON uses the SYS.IMON.SCI file, which contains pubset IDs. If the SCI file is located on the pubset which is split and renamed, when renaming takes place it must be modified manually using /MODIFY-IMON-SCI (see the “IMON” manual [11]). The PVSREN program does this automatically.

• SF pubsets can also be renamed automatically with the following commands, each with the NEW-PUBSET=*SPECIAL-VSN operand, to avoid confusion with the original.

  • Command /START-SNAP-SESSION

  • Command /START-CLONE-SESSION for QuickOPC clones or /ACTIVATE-CLONE for EC-Clones

  • Command /HOLD-REMOTE-COPY for Remote-Copy-pairs. The period in a VSN is changed to a colon; in the case of single-digit catalog IDs, the “PUB” string is changed to “P:B”. Backups using the software product FDDRL are then performed using the original VSN and can be restored under the original VSN. For information on FDDRL, refer to the "FDDRL" manual [9].

• When System Managed Storage and HSMS (see the “HSMS” manual [10]) are used, Snap or clone sessions only duplicate the S0 level (normal processing level) of the pubset; migrated files consequently exist once only on the tape and in the HSMS directory.
  

  CAUTION!
  No files may be migrated or restored on the additional mirror pubset. Otherwise data can be lost.

• Paging files are renamed automatically. If pubset IDs or VSNs have been programmed into the applications, these must be adjusted manually.
  The PVSREN program can complete renaming operations performed by SHC-OSD for IMON, SYSID and the default pubset for user IDs.

If the pubset is not renamed, the snap units cannot be used in the same system because they have the same VSN. They can, however, be used by another server or a virtual machine.

Consistent splitting of a pubset in the shared pubset network

Requirements:

• No DAB write caching may be active.

• All sharers have SHC-OSD started.

• The command is executed on the master.

• There must be MSCF connections between the master and all sharers.

• The pubset may not have the QUIET status.

The UNIT=*BY-PUBSET(...,HOLD-IO=*UNTIL-ACTIVATED) operand, enables an activation at a synchronization point during ongoing operation without exporting the pubset. Shared pubsets with multiple sharers in a CCS network can also be split consistently. This function interrupts all outputs to the pubset during splitting. It is therefore possible, for example, to create a consistent copy of the home pubset during ongoing operation and to back it up or use it in parallel as a standby pubset.

During separate processing of the snap units, actions which entail a high level of updating, such as data reorganization using SPACEOPT, must be avoided on the original pubset.

CAUTION!
/RESUME-IO can be used to resume suspended input/output activity for pubsets.
This command is provided for emergencies only and if used without due care may endanger data consistency on the split snap units.

When an original unit is reformatted using the VOLIN utility routine, VOLIN terminates all snap sessions with this original unit following a query. Reformatting the snap unit with VOLIN is always rejected for ETERNUS DX/AF.

Private disks

The following special aspects must be borne in mind for snap pairs on private disks:

• Private disks cannot be renamed.

• The applications must be terminated.

• The HOLD-IO operand is not supported.

• Private disks must be released using /SET-DISK-PARAMETER with the ASSIGN-TIME=*USER operand.