Browse Prior Art Database

Safe Method for "Waking Up" a Service Process

IP.com Disclosure Number: IPCOM000044191D
Original Publication Date: 1984-Nov-01
Included in the Prior Art Database: 2005-Feb-05
Document File: 3 page(s) / 64K

Publishing Venue

IBM

Related People

Obermarck, RL: AUTHOR [+2]

Abstract

This invention relates to a method for avoiding a functional recovery "window" in a multi-CPU MVS (Multiple Virtual Storage) system when a process invoking a target process fails. This method utilizes self-serialization of the target process. The steps include requiring each executing process to set a flag using atomic instructions. A target process, when invoked, tests and sets the flag. That is, if the flag is "on", then the target process goes to "sleep". If the flag is "off", then the target process sets the flag "on" and executes. The environment where multiple processes which can request a service to be performed by a single server-process is a common one.

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

Page 1 of 3

Safe Method for "Waking Up" a Service Process

This invention relates to a method for avoiding a functional recovery "window" in a multi-CPU MVS (Multiple Virtual Storage) system when a process invoking a target process fails. This method utilizes self-serialization of the target process. The steps include requiring each executing process to set a flag using atomic instructions. A target process, when invoked, tests and sets the flag. That is, if the flag is "on", then the target process goes to "sleep". If the flag is "off", then the target process sets the flag "on" and executes. The environment where multiple processes which can request a service to be performed by a single server-process is a common one. For example, Print SPOOLing, in which many (possibly concurrent) processes each create output destined for a common printer, is serviced by a single output writing process. Another environment is to be found in the IMS/VS Logger where a single task is responsible for writing buffers to the log data set. Other tasks, filling the buffers with logical log records, are responsible for ensuring that the task responsible for writing filled and truncated buffers is "awakened". These other tasks execute in an environment which can be considered unsafe; therefore, they must be expected to fail during the "awakening" process. When a failure occurs, there is a functional recovery "window" in which the writing process may either not be awakened at all, or functional recovery may awaken the writing process multiple times. This situation is more critical when the service routine must be serialized, and runs under an execution unit or process which must be created (e.g., in the MVS Operating System, this would normally be an SRB (Service Request Block)). The current functional recovery procedure is to abnormally terminate the service subsystem if the failure is known to have occurred in the "window". While the "window" is very small (i.e., several machine instructions), it does exist. For critical services, even a small "window" which would cause the service to be abnormally terminated is intolerable. Several "Service" processes, such as the process to execute the gathering of written logical records into buffers to be written, must be "Awakened" by execution units whose home is outside the Journal Interface Service Processes. A method which is tolerant to the possible failure of the process attempting the "Awakening" is required for the successful operation of the J...