Implementation of Automatic Plan Switching Within an Object-Oriented Environment
Original Publication Date: 1991-Jun-01
Included in the Prior Art Database: 2005-Apr-02
Okruw, SK: AUTHOR [+2]
Disclosed is a mechanism that isolates underlying DB2* plans from application classes in an object oriented system.
Implementation of Automatic Plan Switching Within an
a mechanism that isolates underlying DB2*
plans from application classes in an object oriented system.
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".
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.
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.
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
initiated, an application attaches a predefined default
plan which is used to load a set of plan names with corresponding
plan numbers into storage.
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
3. It attaches the new plan; and
4. It retains the plan number.
preferred implementation, a Database class, a Plan
Number table, and a Plan Name table are defined.