Browse Prior Art Database

Detecting Remote Errors From a Local System

IP.com Disclosure Number: IPCOM000035895D
Original Publication Date: 1989-Aug-01
Included in the Prior Art Database: 2005-Jan-28
Document File: 3 page(s) / 26K

Publishing Venue

IBM

Related People

Barrett, J: AUTHOR [+4]

Abstract

Problem solved: A special way to unlock all distributed processes running on the local system when an error is detected on the remote system. Description of Invention:

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 53% of the total text.

Page 1 of 3

Detecting Remote Errors From a Local System

Problem solved: A special way to unlock all distributed processes running on the local system when an error is detected on the remote system. Description of Invention:

A. Background: The Distributed Services (DS) LPP uses the SNA system to send and receive DS data. However, when the remote DS system detects a SNA error, all the local DS processes should get notification. Otherwise, all the local DS processes will get hung up waiting on the server response. In this invention, a special error recovery design is incorporated in the SNA system so that the error notification will be performed by SNA when DS discovers an error condition.

B. Description of Invention: A local DS process communicates with another process on a remote RT via a SNA session. When the local DS process issues a write command to the remote RT, the SNA system generates an Attach Request to the remote RT. On the remote RT, SNA interfaces with the DS system to create the kernel process (see figure below). At the local RT, once the write command is completed, the local DS process immediately issues the read to reconnect. Under this condition, the DS process is put to sleep in SNA to wait for the reconnect. However, awakened the DS process does not control any SNA session, and under the current architecture, the local process will not be awakened because error notification is performed only at the session level. Since the local process is not controlling any session, error notification to the local process is not done. Thus, the local process will be waiting forever for a response. Because of the above situation, an error recovery interface at the kernel level is created via the following function: lu6kccb (kccb, type...