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

Technique for Supporting Environment-Independent Exit Routines

IP.com Disclosure Number: IPCOM000130733D
Original Publication Date: 2005-Nov-03
Included in the Prior Art Database: 2005-Nov-03
Document File: 7 page(s) / 41K

Publishing Venue

IBM

Abstract

A technique for providing operating environment independence for exit routines is described, which allows applications invoking exits to provide a services interface to exits. This allows exits to be implemented so that they need no access to their operating environment.

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

Page 1 of 7

Technique for Supporting Environment -Independent Exit Routines

At one time, it was common practice for software customers to make source-code modifications to commercial products, so as to provide local extensions or variations, or to satisfy organizational requirements. While a popular activity, such modifications made it far more difficult to determine the origins of problems -- whether they were in the original product, in the local modifications, or in an interaction between the two.

These and other difficulties encouraged producers of software to provide customers with a controlled means of providing for local tailoring, decision making, and function evaluation, rather than trying to implement all such requested capabilities in the base product itself. Typically, these means are provided by exits at various points from the base product where local decisions may be made, additional information can be provided, etc. Other uses of exits may include re-processing and post-processing of data read and written by the base product.

We use the term "exit" here to mean any user-written (or user-modified version of a commercial product-supplied template or skeleton) that may optionally or normally be invoked by the base product to derive additional information supplied to the base product by the exit. Exits can also include facilities for evaluating external functions, as described in reference (1) below.

Exits that need operating environment services can sometimes contend for the same resources used by or required by the base product. For example, an exit may require working storage that may not be available due to the base product's previous allocations; both the exit and the base product may try to write messages to the same file; or, both the exit and the base product may both need to communicate with the user interface or with some remote facility. Such simultaneous requests for services can cause sequence-dependent or timing-dependent errors that are difficult to detect and diagnose.

A further difficulty arises if the base product executes in more than one operating environment, and supports similar exits in each such environment. Each implementation of such exits that uses resources and capabilities of those environments must then be tailored to the specific environment in which the base product executes. This can require costly test suites and regression testing for each such environment; the added expense of constructing the "test bed" (implementing the base product and testing environment for each operating environment) as well as separate testing scaffolding appropriate to each environment, is clumsy, costly, time-consuming, and highly error-prone.

Typical implementations of exits that must run in multiple operating environments must often use either conditional compilation or conditional assembly capabilities; or worse, separate implementations of the same exit functionality must be written to build the exit for each suppor...