Browse Prior Art Database

Implementation of Automatic Plan Switching Within an Object-Oriented Environment

IP.com Disclosure Number: IPCOM000120739D
Original Publication Date: 1991-Jun-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 4 page(s) / 166K

Publishing Venue

IBM

Related People

Okruw, SK: AUTHOR [+2]

Abstract

Disclosed is a mechanism that isolates underlying DB2* plans from application classes in an object oriented system.

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

Implementation of Automatic Plan Switching Within an Object-Oriented
Environment

      Disclosed is a mechanism that isolates underlying DB2*
plans from application classes in an object oriented system.

      It is desirable, in a batch or TSO object-oriented environment
or any TSO or batch application where the interaction of several
modules constitute an application, to isolate modules in different
DB2 plans.  This is because it is often necessary to drop and
re-create tables in a production environment which results in the
"invalidation" of DB2 plans.  Therefore, if an application that is
made up of several modules has only one plan, invalidation of that
plan causes the whole application to come to a stop.  On the other
hand, if the application is made up of several plans, then only part
of the application becomes "nonexecutable".

      Multiple plans also afford the user the capability to use
different parameters on the bind statements for the different plans.
This capability can be used to make modules access different tables
or make critical applications acquire their resources at the start of
the application instead of at the time the resources are needed; or,
more generally, it allows the user to tweak the bind parameters for
each plan to suit the environment.

      This multiple plan capability is fully implemented in CICS and
IMS, but is only enabled in TSO and batch through the availability of
the DB2 CALL ATTACH facility.

      Therefore, the disclosed database access switching mechanism
has the following minimum characteristics:
     All the knowledge about the access method is
     encapsulated within a single database class;
     There is no connection between the external grouping of
     modules within plans and classes which contain SQL,
     thus allowing complete freedom to bind plans as
     desired;

      When initiated, an application attaches a predefined default
plan which is used to load a set of plan names with corresponding
plan numbers into storage.

      As each module in the application is executed it requests the
database module to attach the appropriate plan for it before it
executes the SQL code.

      In a central table, each application module is associated with
a plan number or a list of plan numbers. When the application module
makes a request for attachment of the appropriate plan, the database
module does the following based on the plan number that is associated
with the requesting module:
1.   It detaches the existing plan if its number does not
     match any of those of the requesting module;
2.   It translates the plan number for the requesting module
     into a plan name by accessing the list of plan names in
     storage;
3.   It attaches the new plan; and
4.   It retains the plan number.

      In the preferred implementation, a Database class, a Plan
Number table, and a Plan Name table are defined.
Databa...