Browse Prior Art Database

IMS/VS Data Sharing Enhancements (Dynamic Reconfiguration to INITIAL State)

IP.com Disclosure Number: IPCOM000042746D
Original Publication Date: 1984-Jun-01
Included in the Prior Art Database: 2005-Feb-04
Document File: 5 page(s) / 42K

Publishing Venue

IBM

Related People

Beier, HA: AUTHOR [+4]

Abstract

This article describes a method for operating a computing apparatus that experiences a communications failure between resource lock managers in a multihost data sharing environment to allow each resource lock manager to independently recover from the failure and reach an initial state where full lock granting protocols are in effect. This is accomplished by operating a first resource lock manager to dynamically reconfigure (back out and close) shared data base usage to reach a known safe point and to cease all conflicting use of all globally shared data bases, and thereafter to purge locks held in the other resource lock manager from the first resource lock manager to restore the first resource lock manager to the initial state. In the IBM Information Management System (IMS/VS 1.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 29% of the total text.

Page 1 of 5

IMS/VS Data Sharing Enhancements (Dynamic Reconfiguration to INITIAL State)

This article describes a method for operating a computing apparatus that experiences a communications failure between resource lock managers in a multihost data sharing environment to allow each resource lock manager to independently recover from the failure and reach an initial state where full lock granting protocols are in effect. This is accomplished by operating a first resource lock manager to dynamically reconfigure (back out and close) shared data base usage to reach a known safe point and to cease all conflicting use of all globally shared data bases, and thereafter to purge locks held in the other resource lock manager from the first resource lock manager to restore the first resource lock manager to the initial state. In the IBM Information Management System (IMS/VS 1.2), when extreme error or failure conditions are encountered where two resource lock managers (IRLMs) are no longer able to communicate, an effort is made to have the two IRLMs re-establish the VTAM session. There is very little recovery action performed which would leave the remaining IMS subsystem usable. When doing multihost block level data sharing, the following three failures are time consuming and operationally difficult to recover from: (1) one IRLM abends, (2) one host fails (maybe hardware), and (3) VTAM on one or both of the hosts fails, or the hardware communication link between the two hosts fails. Recovery from these failures is difficult for an installation to manage because manual data base reconfiguration is sometimes needed to make shared data bases re-usable again. The current status of every data base that could be used by any participating IMS/VS subsystem remains unknown until the Data Base Administrator has time to list the DBRC RECON data sets and determine (1) which data bases need to be DBRed in which IMS/VS control regions, (2) which IMS/VS batch jobs need to be terminated (that haven't already abnormally terminated), and (3) which batch and online regions need to have batch backout or emergency restart performed. Any batch backout or emergency restarts have to be run once on each host in order to have each IRLM purge retained locks. These actions by the Data Base Administrator are necessary in order to allow the IMS/VS subsystems or some of their applications to continue to run. The solution to the above problem is to have each IMS/VS subsystem operating under an IRLM participate in the recovery, and guarantee to its IRLM that it will not request another lock which may be in conflict with locking on another IRLM, whether or not the other IRLM is alive or dead. By so doing, one IRLM no longer needs to retain any of the locking or subsystem information from the other IRLM. When one IRLM can 'throw away' all information from the other IRLM, it can assume INITIAL state and restore full lock granting protocols because every IMS/VS subsystem under it has guara...