Single-Source Reference/Multiple Table Access via DB2 Synonyms
Original Publication Date: 1994-Mar-01
Included in the Prior Art Database: 2005-Mar-26
Publishing Venue
IBM
Related People
Hart, TP: AUTHOR [+3]
Abstract
The ImagePlus* Batch processes need to be able to access and update data which reside in, what has been termed by the ImagePlus MVS/ESA* platform, TABLESETs. This construct means that data from various applications, which comprise the same DB2 table attributes, are stored and managed in "mirror" tables. This was done for many reasons, but mainly to allow for:
Single-Source Reference/Multiple Table Access via DB2 Synonyms
The
ImagePlus* Batch processes need to be able to access and
update data which reside in, what has been termed by the ImagePlus
MVS/ESA* platform, TABLESETs. This
construct means that data from
various applications, which comprise the same DB2 table attributes,
are stored and managed in "mirror" tables. This was done for many
reasons, but mainly to allow for:
o a separation of data by application, and
o the need for
customers to store greater than 64 gigabytes of data
(e.g., capacity limitation on DB2
tablespaces).
The batch
processes run in a CAF environment which will allow a
single task to connect to a DB2 subsystem, open a DB2 plan (a thread
connection to DB2) that should be opened, and process data related to
the plan. A single plan contains the
access paths and pointers to a
"SET" of "TABLES," thus the term TABLESET. But another plan contains
a complete set of the same tables WITH DIFFERENT NAMES.
In our batch
process design and implementation, we accommodate
all tablesets via ONE set of code pointing to a single reference.
For example, our code might appear as:
o SELECT * FROM TABLE00
Based upon
DB2 synonyms, which are USERID oriented, we need to
BIND a plan that contains the DBRM for the above SELECT statement,
and point the reference "TABLE00" at a REAL table within a
tablespace. This plan gets utilized when
it is OPENed within the...