Browse Prior Art Database

Preserving System Integrity Across Detach and Reattach of a Geographic Mirror Copy

IP.com Disclosure Number: IPCOM000012262D
Original Publication Date: 2003-Apr-23
Included in the Prior Art Database: 2003-Apr-23
Document File: 2 page(s) / 45K

Publishing Venue

IBM

Abstract

The following describes a programming method that allows a physical copy of user data (like an independent auxiliary storage pool (IASP)) on a system (production system) to be made on a separate set of disk drives (geographic mirror copy) and used on a second system (target system) without any data integrity problems if the copy is destroyed and the production copy of the data is switched to the second system or another copy of the updated user data is made at a later time to be accessed on the second system.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

  Preserving System Integrity Across Detach and Reattach of a Geographic Mirror Copy

  Each independent auxiliary storage pool (IASP) has a virtual address range assigned to it by the system. This allows the system to know which IASP an object is in when it is referenced. Therefore, there is only one current range assigned to the IASP that is being mirrored that is used to create new objects. When the IASP is copied by a storage subsystem, or a remote geographic mirror is detached, the mirror copy can be accessed and used on the target system just like the production copy is being used on the source system. Both copies of the IASP need to have knowledge of the current virtual address range being used so that each of the systems can reference and use the objects in the IASP that have been assigned those virtual addresses . Because both copies of the IASP are being used, (the production copy may still be in use while the copy is being used to perform a save) new objects can be created on both copies of the IASP. Since both copies of the IASP have the same current virtual address range, they will create objects with the same virtual address. The pointers to those objects can be stored in objects in another auxiliary storage pool (ASP), like the system ASP, on the system. Therefore, each system has pointers that contain the same virtual address, but point to completely different objects.

    When the remote geographic mirror copy is reattached, full synchronization will occur to make the mirror copy an exact copy of the production copy again. For a storage subsystem, another mirror copy can be made from the production copy when another save or other function that can be done from a mirror copy is needed. In either case, the target system that used the first copy of the IASP now has a second copy of the same IASP. It can also have objects in a different ASP that contain pointers to objects that were created while the first copy was being used on it. Those objects no longer exist because the first mirror copy was destroyed and the latest data from the production copy was copied to it. Those old pointers on the target system have the same virtual address as objects that were created on the production copy while the remote geographic mirror was detached. The objects created on the production copy and referenced by those virtual addresses now exist on the mirror copy as the result of the second copy being detached (or storage subsystem copy). This makes the old pointers on the target look valid because there are objects that exist on the latest copy of the IA...