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

Os/2 Extended Edition Database Services Return Code Design

IP.com Disclosure Number: IPCOM000036766D
Original Publication Date: 1989-Oct-01
Included in the Prior Art Database: 2005-Jan-29
Document File: 3 page(s) / 15K

Publishing Venue

IBM

Related People

Horn, GR: AUTHOR [+3]

Abstract

Disclosed is a method within a program for returning error information from low level components/functions up to a common error handler responsible for logging error information interpretable by the calling application or end user.

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

Page 1 of 3

Os/2 Extended Edition Database Services Return Code Design

Disclosed is a method within a program for returning error information from low level components/functions up to a common error handler responsible for logging error information interpretable by the calling application or end user.

OS/2* Extended Edition provides an API to the database management system (DBMS) that adheres to the Systems Application Architecture (SAA) Common Programming Interface (CPI) for database. This CPI defines the SQL Communications Area (SQLCA) as the common mechanism for returning error information to the calling application after execution of SQL statements. Errors are mapped to SQLCODEs in similar manner for all SAA database products.

Given a system design with multiple components that detect errors and a single component that logs errors, and given the SAA requirement, as described above, a design was required for passing return codes from lower level components/functions back up to the level where the error could be translated into the appropriate SQLCODE and, along with any other information required for problem determination and subsequent processing, stored in the SQLCA. Return codes were designed to meet the following objectives:
1. A return code is a 16-bit integer.
2. An error return code must be easily distinguishable

from a successful return code.
3. In some cases, a number of different return codes must

map to a number of different SQLCODEs.
4. In other cases, a number of different return codes must

map to a single SQLCODE. The original error must be

identifiable with a unique reason code (subcode).
5. The data available for determining problems from the

field could include the SQLCODE, original return code,

and reason code. This must allow identification of the

component detecting the error and the actual error

condition.
6. Certain sets of errors would require special action.

In particular, certain sets of errors would indicate

that the database was bad or that the communication

link was bad.
7. For errors internal to a component, it must be a

straightforward task to assign a return code that does

not conflict with any other component's return codes.

To meet these objectives, Error Return Codes were encoded as follows (where bit 0 is the most significant bit): Bit 0 Always 1 to denote a negative value

(error)

Bits 1..3 Error Class (up to 8 classes)

Bits 4..7 Component ID (up to 16 components)

Bit 8 Reserved for extra component IDs or

reason codes

(whichever is needed later)

1

Page 2 of 3

Bits 9..15 Reason Code (up to 128 codes per class)

Equates were defined for each error class with bit 0 preset. Equates were also defined for each component. Reason code equates were defined within each error class for each known error condition. Return code equates were defined by each component as the logical sum the error class equate, the component ID equate and the reason code equate.

Error classes were defined in such a way that within a class...