Browse Prior Art Database

Dynamically Generated Insertion Ring Configuration Table for a Distributed Data Processing System

IP.com Disclosure Number: IPCOM000034812D
Original Publication Date: 1989-Apr-01
Included in the Prior Art Database: 2005-Jan-27
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Hall, WD: AUTHOR [+3]

Abstract

This article describes a technique for simple maintenance of an insertion ring configuration table of a distributed data processing (DDP) system whose nodes are being powered down, powered up or being altered or moved. In a DDP system, nodes may be powered down, powered up, become inoperable, or altered. As such, it is necessary to maintain an up- to-date configuration table of the DDP system to back out or cancel applications, to move applications, or to restart or initialize applications that have been terminated.

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

Page 1 of 2

Dynamically Generated Insertion Ring Configuration Table for a Distributed Data Processing System

This article describes a technique for simple maintenance of an insertion ring configuration table of a distributed data processing (DDP) system whose nodes are being powered down, powered up or being altered or moved. In a DDP system, nodes may be powered down, powered up, become inoperable, or altered. As such, it is necessary to maintain an up- to-date configuration table of the DDP system to back out or cancel applications, to move applications, or to restart or initialize applications that have been terminated. This can be accomplished by monitoring the insertion ring for nodes which either appear (powered on or connected to the ring) or disappear (powered off, become inoperable, or disconnected) and update the configuration table as appropriate and interrupt or inform the system as to the status of the node that has been altered. In a DDP system, such as the one disclosed in [*], the local insertion bidirectional ring architecture allows for high availability via the use of two rings which transmit data in opposite directions. When a failure occurs, the system operations port (SOP) is notified of the failure and will take the appropriate steps to circumvent the problem completely without software intervention. In order to accomplish failure recovery of the ring, the physical location of the failure must be known. Since the ring addresses are logically assigned as the drops are connected to the ring, the SOP must be able to locate a physical failure within this logical environment. To accomplish the failure recovery, the SOP generates and maintains the ring configuration table. The ring configuration table contains the relative physical location of the logical drops on the ring and all the information required to be able to uniquely identify each drop. The relative physical location of each of the drops is defined through the use of various Restricted Broadcast orders which automatically generate the logical address to a physical location relationship. This is done by the inserting of the ring address at the end of the data of the order as each drop acknowledges the order. The data returned to the port that issued the order thus represents the physical sequence of the logical ring addresses around the ring on which the order was issued.

The following is a list of the orders which can be used to generate the physical sequence: 1. Broadcast Availability Status 2.

Broadcast Address Select 3. Broadcast Address Select and Return With the physical sequence information and the drop configur...