Browse Prior Art Database

Technique for Proper Detection of Long I/O on IMS RECON Dataset

IP.com Disclosure Number: IPCOM000241314D
Publication Date: 2015-Apr-16
Document File: 3 page(s) / 52K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to detect "Long I/O" for RECON (RECovery CONtrol) dataset on IMS (Information Management System) properly without erroneous decision on which redundant dataset should be removed.

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

Page 01 of 3

Technique for Proper Detection of Long I/O on IMS RECON Dataset

Disclosed is a method to detect "Long I/O" for RECON (RECovery CONtrol) dataset on IMS (Information Management System) properly without erroneous decision on which redundant dataset should be removed.


1. Background

The OS and middleware on IBM z Systems have been implementing the mechanism of having redundant data files on hard disks and removing one of them immediately in case of I/O error to proceed with other normal (non-erroneous) data file. However, when the I/O for one of the redundant device cannot make response for some reason for a long time without errors, normal I/O response time cannot be maintained even if the other redundant device is normally operating, The state that such I/O response is not returned to for a long time is called "Long I/O*". A function called "I/O Timing facility (IOT)*" is implemented to detect this Long I/O state within z/OS. In IOT, a user sets a time-out value of I/O response to the volume beforehand. It is the function to detect this Long I/O state when a response of I/O does not return before this time-out value. In this way, an obstacle device can be removed immediately at the time of Long I/O outbreak and the processing can be resumed by I/O to the normal device. So, normal I/O response time can be maintained. In Long I/O recovery by IOT, when both of redundant devices suffer Long I/O at the same time, the means to evade the situation that suffer the system down by removing both of redundant devices at the same time is implemented. Even if the secondary device suffer Long I/O when the primary device enter into Long I/O state, it is not removed. There is an advantage that the possibility that processing can be continued is left when Long I/O state on secondary device is resolved after reaching I/O time-out value on secondary device.


2. Problem

IMS is one of the middleware on z/OS. IMS has a data set to manage a recovery processing called "Recovery control data set (RECON)". RECON has the redundancy because of having duplexed data set. IMS will make update I/O to both RECON in the same way. These duplexed RECON are shared with two or more systems. IMS has an exclusive control function to maintain data integrity when two or more systems make update to the same RECON at the same time. [Figure 1]. This mechanism of exclusive control has a problem in Long I/O recovery for RECON.

The duplexed RECON is called COPY1 or COPY2 for each. When one system makes I/O to RECON, it issues RESERVE command to prevent other systems from making I/O to the same RECON at the same time. The system attempting to make I/O to RECON issues RESERVE command before making I/O. When I/O is completed, The system release RESERVE condition to resume I/O to be made from others. The system issues RESERVE command to both RECON in order of COPY1 and COPY2 . COPY2 is reserved with reserving COPY1. Therefore, when I/O to COPY2 from System1 is suffered Long I/O, I/O to...