Each data adapter is an RDBMS application; the particular RDBMS determines how its adapter is implemented. |
In this section: Implementing the DB2 Data Adapter as an RDBMS Application Implementing the Teradata Data Adapter as an RDBMS Application Implementing the IDMS/SQL Data Adapter as an RDBMS Application Implementing the Oracle Data Adapter as an RDBMS Application |
The adapter functions as an RDBMS application that normally executes dynamic SQL. As such, it must be registered with the RDBMS in the same way as any other application.
All applications that access DB2 tables on MVS or VM go through a precompile procedure prior to normal compilation. The precompiler copies all of the SQL statements from the application into a separate module called a Database Request Module (DBRM). It also modifies the original application program by transforming its SQL statements into comments and replacing them with calls to the DBRM. The modified application program can then go through the usual process for creating an executable load module.
The SQL statements from the original application program must also be made executable. The DBRM undergoes its own compilation and optimization process called a bind. The bind optimizes the SQL code, performs security checking, and determines the most efficient access path to the required data (the access path identifies available resources, such as specific indexes and scan methodologies for traversing the data source). The result of the bind is called an application plan in DB2 on MVS and an application package in DB2 for VM.
There are three ways of binding DBRMs into an application plan. One is to bind all of the DBRMs for an application into one large plan; the second is to bind each DBRM into a separate plan. The third is to bind separate DBRMs into small application packages, which you then bind into a special type of application plan that consists of pointers to each application package. The advantage of this alternative is that you can re-bind individual packages without having to re-bind the entire application plan. In a distributed database environment, application packages are essential.
During execution, the program load module works in conjunction with the application plan or access module under control of the RDBMS.
The following diagram illustrates the process of preparing an application for execution:
You can use either dynamic or static SQL in TABLE and MODIFY requests. Dynamic SQL is the default for the data adapter; however, even to use static SQL, you must have the data adapter installed. The choice of dynamic or static SQL has the following effects on compilation and bind processing:
At run time, the data adapter executes static MODIFY procedures without further processing.
However, prior to executing a static TABLE request, the data adapter re-generates the SQL in the request. It then compares the current SQL to the SQL generated during compilation. If the SQL has not changed, the data adapter executes the FOCEXEC. Because of this extra step, you can run an altered TABLE request without re-binding it, as long as the SQL generated by the TABLE request has remained the same.
Static SQL (DB2 and DB2 for VM) discusses the advantages of static SQL and describes static module creation.
The Teradata Data Adapter is an application program that contains dynamic SQL only. No preprocessing is required when installing the data adapter. The Teradata Data Adapter is delivered as a load library. On MVS, you must link-edit it with the Teradata libraries; On VM, you must copy the data adapter load libraries to the Teradata production disk.
The Teradata RDBMS and data sources reside on a UNIX box. The data adapter on MVS or VM communicates with the Teradata RDBMS on UNIX using the Teradata Director Program (TDP) communicating across a Block Multiplexor Channel. The communications link between your address space and the Teradata Director Program (TDP) is implemented with either MVS/XMS (Cross Memory Services) or Supervisor Call (SVC). Your systems programming group determines the type of link during Teradata installation. On VM, the communications link between your virtual machine and the Teradata Director Program (TDP) is implemented using the VM Inter-User Communications Vehicle (IUCV).
The following diagram illustrates this configuration:
The IDMS/SQL Data Adapter is an application program that contains dynamic SQL only. No preprocessing is required when installing the data adapter. The IDMS/SQL Data Adapter is delivered as a fully executable load module.
The Oracle Data Adapter is an application program that contains dynamic SQL only. No preprocessing is required when installing the data adapter. The Oracle Data Adapter is delivered as Assembler code. On MVS, you must assemble the code and link-edit it with the Oracle libraries; On VM, you must assemble and link it with the Oracle load libraries and copy these libraries to the Oracle production disk.
| Information Builders |