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

User Exit Creation in Multiple Virtual Storage Open/Close/EOV Code

IP.com Disclosure Number: IPCOM000105759D
Original Publication Date: 1993-Sep-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 2 page(s) / 85K

Publishing Venue

IBM

Related People

Avis, MJ: AUTHOR

Abstract

Disclosed for an MVS* system is a technique to remove the impact of subsequent software maintenance on user-introduced exits in the Open/Close/EOV code.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

User Exit Creation in Multiple Virtual Storage Open/Close/EOV Code

      Disclosed for an MVS* system is a technique to remove the
impact of subsequent software maintenance on user-introduced exits in
the Open/Close/EOV code.

      In Multiple Virtual Storage (MVS), when an installation or
software vendor wishes to gain control during the opening and closing
of datasets, the usual approach is to modify the code, via the
maintenance utility AMASPZAP, possibly having first expanded the
CSECT to be modified using the linkage editor.  Such a process is
difficult to maintain because the application of any maintenance
later distributed may replace the changes with new code, which means
that old changes must be re-applied.  If code offsets have changed,
the change may need to be re-worked.  The overhead of maintaining
such hooks may be reduced if control is only required at points where
one CSECT transfers control to another.  This is not a major
restriction because individual CSECTs are small and provide only an
individual function.

      The introduction of modifications where CSECTs transfer control
requires new CSECTs to be created, with the same name as the target
CSECT, the one to which control is to be transferred.  These new
CSECTs must be link-edited with the original module at the same time
as the original CSECT with the same name is renamed by the link
editor to a name known by the new CSECT and to which it will transfer
control on completion of its new function.  This arrangement may yet
be impacted by maintenance.  If a renamed CSECT is subsequently
replaced by maintenance, the link editing to rename the CSECT will
need to be re-run, but, unless a major re-structuring of the code
occurs, re-working the control statements for the linkage editor will
be unlikely.

      New thinking about acquiring control in open and close was to
create unique CSECTs which could be linked with the standard CSECTs
in the modules, then modify the transfer address information at or
after system initialization time to ensure that the new CSECTs
acquire control at the appropriate points.  Such a process will
rarely be impacted by maintenance, unless a major restructuring of
the functions in individual CSECTs is changed.  Modification of the
flow of control at or after system initialization time is made
possible for open and close components because transfer of control is
effected using control blocks called XCTL Tables.  Each CSECT has an
XCTL table entry for each other CSECT to which it wishes to tr...