Browse Prior Art Database

Exit Driver Concept Disclosure Number: IPCOM000031040D
Original Publication Date: 2004-Sep-07
Included in the Prior Art Database: 2004-Sep-07
Document File: 1 page(s) / 27K

Publishing Venue



IBM provides "user exit" points in many of it's software products. IBM normally supplies sample exit code and/or proprietary object-code-only exits appropriate to the exit point, e.g. sign-on, data translation, sign-off.. However, as software has evolved and some users have exploited an exit for their own purposes, then they are left with a dilemma if IBM supplies a new function for the exit. If they wish to use the new function they must either rewrite their own exit, or if the new IBM supplied function is more important than their existing exit, then they must replace their exit with the new IBM exit. An exit driver would resolve this issue. The exit driver could call the user's exit before or after the new function exit, as required by the processing sequence. In fact multiple exit programs could be called in sequence from one exit driver program. The exit driver would in effect be a traffic cop for executing a sequence of exit sub-routines. As far as I know, there are no exit drivers, at least on the S390 platform.

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

Page 1 of 1

Exit Driver Concept

An example of a problem this driver would solve would be when using the IMS segment edit/compress routine, a data translation exit is described as follows.

A user cannot compress IMS segment data (to save DASD space) and encrypt data (for security) in a single exit unless they code their own complex routine. As encryption is normally driven by legislature, the user is forced to forgo DASD savings in such an instance. An IMS application would pass input data to the driver, which in turn would pass it to the first sub-routine to be called. The translated output from the first sub-routine would then be passed back to the driver. The driver would then pass the data to the next sub-routine, and so on. When the last routine is complete then the driver would pass the multiply translated data back to the calling application. This type of driver could be implemented WITHOUT making any changes to the existing routines it calls, so the only thing the user would have to determine is the sequence of the exits prior to linking/binding the routines with the driver.

Driver logic pseudo code

Get input data address from caller

Get output area address from caller
Get parmlist address from caller
Point to first exit in driver's vector table (created by link/bind of driver and exits) Do while exits in vector table Invoke exit, passing input data address, output data address, parmlist

Point to next exit in vector table

Pass input data address, output data address...