Browse Prior Art Database

ADDING SECONDARY TIMESTAMP TO ASYNC PPRC

IP.com Disclosure Number: IPCOM000015762D
Original Publication Date: 2002-Oct-19
Included in the Prior Art Database: 2003-Jun-21
Document File: 1 page(s) / 45K

Publishing Venue

IBM

Abstract

Problem Hosts that use Clean-Copy Async PPRC are granted that, at any time, the secondary storage is a consistent copy ofthe primary storage. However, due to the asynchronous nature of this function, the secondary storage is not necessarily a fully up-to-date copy of the primary storage. Solution A Secondary Timestamp provided by the subsystem. The Secondary Timestamp may help the host software in the realization of such a recovery strategy for Clean-Copy Async PPRC. To use this capability, the host must provide a synchronized timestamp in each of the host writes. This mechanism allows the host to query the secondary subsystem, getting a timestamp t , for which it is granted that any host writes with timestamp t were already propagated to the secondary.

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

Page 1 of 1

ADDING SECONDARY TIMESTAMP TO ASYNC PPRC

Problem

    Hosts that use Clean-Copy Async PPRC are granted that, at any time, the secondary storage is a consistent copy ofthe primary storage. However, due to the asynchronous nature of this function, the secondary storage is not necessarily a fully up-to-date copy of the primary storage.

Solution

    A Secondary Timestamp provided by the subsystem. The Secondary Timestamp may help the host software in the realization of such a recovery strategy for Clean-Copy Async PPRC. To use this capability, the host must provide a synchronized timestamp in each of the host writes. This mechanism allows the host to query the secondary subsystem, getting a timestamp t, for which it is granted that any host writes with timestamp < t were already propagated to the secondary.

    The secondary subsystem owns the variable secTS. Whenever the secondary subsystem is queried for a timestamp, secTS will be returned as an answer. When the session is established, secTS on the secondary subsystem will be initialized to 0.

    SN-GEN will own an additional variable, called currentTS that is initialized to 0 when the session starts. Whenever SN-GEN is called to allocate an SN, the client may (or may not) specify a timestamp. If timestamp is not specified, no further modifications are required. If timestamp ts is specified, then:

    If ts > currentTS, then SN-GEN will set currentTS to ts and return the new SN and ts to the client.

    If ts <= currentTS, then SN-GEN wil...