Browse Prior Art Database

Use of Return Codes to Identify Determinate and Indeterminate Errors

IP.com Disclosure Number: IPCOM000080473D
Original Publication Date: 1973-Dec-01
Included in the Prior Art Database: 2005-Feb-27
Document File: 1 page(s) / 12K

Publishing Venue

IBM

Related People

Cole, RG: AUTHOR [+3]

Abstract

In a complex operating system, made up of many hundreds of program modules, it is essential that standard conventions for communication between modules be established. Such a standard allows simplification of code and lowers the level of expertise required to implement and maintain the operating system and allows certain portions of the system to be further modularized (e.g., macros), or even implemented as hardware instructions. This description discusses one portion of the communication between modules of an operating system: the communication of the success or failure of a service requested of a module to the requestor of that function.

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

Page 1 of 1

Use of Return Codes to Identify Determinate and Indeterminate Errors

In a complex operating system, made up of many hundreds of program modules, it is essential that standard conventions for communication between modules be established. Such a standard allows simplification of code and lowers the level of expertise required to implement and maintain the operating system and allows certain portions of the system to be further modularized (e.g., macros), or even implemented as hardware instructions. This description discusses one portion of the communication between modules of an operating system: the communication of the success or failure of a service requested of a module to the requestor of that function.

When a module of code is requested to perform a function, three conditions can occur: 1) The function is successful, i.e., the "normal" condition. 2) The function fails and a means of correcting the failure is known. It is not necessary that the correction be attempted or even described, as long as the means for correction is known. 3) The function fails and no means of correction is known. In this case, only symptoms of the error are known.

A module which has requested a function to be performed by another module will usually want to know whether the function was successfully performed, and if not, whether any corrective action may be taken so that the function will be successful or may be retried. This information may be communicated by the following system...