Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Restartable Wait State

IP.com Disclosure Number: IPCOM000085061D
Original Publication Date: 1976-Feb-01
Included in the Prior Art Database: 2005-Mar-02
Document File: 3 page(s) / 45K

Publishing Venue

IBM

Related People

Sasala, R: AUTHOR

Abstract

A method of communicating with an operator when it is necessary to recover from processor malfunction situations and conflicts arise which make it impossible to do a WTOR (write to operator with reply). Previously, this has resulted in a disabled wait state that necessitates a re-IPL (initial program load) of the system.

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

Restartable Wait State

A method of communicating with an operator when it is necessary to recover from processor malfunction situations and conflicts arise which make it impossible to do a WTOR (write to operator with reply). Previously, this has resulted in a disabled wait state that necessitates a re-IPL (initial program load) of the system.

The present method provides a restartable wait state which can be considered an Instruction Address Register (IAR) WTOR to inform the operator that he is to take an action to resolve the conflict, after which he may press the Restart key and the system may resume operation.

Consider the diagram, wherein CPU 1 and CPU 2 are tightly coupled, i.e., sharing storage and a common operating system A and CPU 1 and CPU 3 are loosely coupled, i.e., not sharing storage or an operating system. Let it be assumed that CPU 1 has issued a reserve command to device A and that CPU 3 has subsequently attempted to likewise issue a reserve command to device A, but has received a busy signal due to the reserve previously issued on CPU 1. Let it further be assumed that the communication code for a WTOR resides on device B and that a contingent connection is outstanding for device C, as for example, after a Unit Check error condition.

Now, if CPU 1 fails, due to a check stop condition, with the assumed reserve outstanding for device A and contingent connection to device C, a malfunction alert signal is issued to CPU 2. CPU 2 must be able to access device B, in order to do a WTOR informing the operator of reserves that must be cleared in such a manner that a loosely coupled CPU, such as CPU 3, does not get control in the interim between breaking the reserves on CPU 1 until they can be reserved from CPU 2. However, the WTOR cannot be issued, since the code needed to do this resides on device B which is connected to the same control unit 3 which has a contingent connection to device C, and a reset would hav...