Oracle® Access Manager for AS/400 Installation and User's Guide 10g Release 2 (10.2) for IBM iSeries OS/400 Part Number B16223-02 |
|
|
PDF · Mobi · ePub |
Oracle Access Manager for AS/400 enables SQL applications on the IBM iSeries to access and modify data in an Oracle database.
Read this chapter for information about the architecture and features of Oracle Access Manager for AS/400. It includes the following sections:
Oracle Database Gateway technology, combined with Oracle Access Manager products, allows you to fully integrate the AS/400 and Oracle systems. The Oracle Database Gateway for DB2/400 and the Oracle Database Gateway for DRDA provide Oracle users with access to AS/400 data as illustrated in Figure 1-1.
Oracle Access Manager provides AS/400 applications with access to Oracle data through SQL statements or stored procedures, as illustrated in Figure 1-2.
Oracle Access Manager for AS/400 provides OS/400 users with access (through DB2/400) to data that is residing on any supported Oracle platform by the use of Oracle SQL or Oracle stored procedures. Oracle Access Manager connects to the Oracle environment through Oracle Net. The connection from the AS/400 to an Oracle server uses TCP/IP.
Access Manager takes advantage of the IBM Application Requester Driver (ARD) interface to access an Oracle server. For a description of this interface, refer to the IBM document for System API Reference.
Access Manager allows direct access to Oracle data from existing AS/400 applications that are written in C, COBOL, or RPG, or from the AS/400 Interactive Query Manager product (STRSQL). Access Manager intercepts SQL statements during program execution and directs them to the Oracle server.
Figure 1-3 shows the architecture of Oracle Access Manager for AS/400.
Figure 1-3 Oracle Access Manager for AS/400 Architecture
The components interact in the following ways:
Table 1-1 Access Manager Component Interactions
Component | Interaction |
---|---|
performs processing and invokes embedded SQL to run SQL statements and retrieve results. |
|
manages connections, receives requests from the application, calls the ARD interface to process SQL requests if the connection is to Oracle, and returns results to the application. |
|
provides an interface between SQL Client Manager and Access Manager. |
|
processes procedure calls, submits SQL requests to the Oracle server, and returns results to SQL Client Manager. It also modifies requests, if necessary, so that they conform to Oracle server syntax. |
|
receives requests from the network and formats them to access Oracle data, then returns results over the network to the client. |
|
allows databases and their applications to reside on different computers and to communicate as peer applications in a Transparent Networking Substrate (TNS). |
The following section describes the features of the Oracle Access Manager for AS/400
AS/400 applications can take advantage of the powerful Oracle SQL language to analyze data that is stored in an Oracle database. Virtually any SQL command can be embedded in an AS/400 application, including INSERT
, DELETE
, UPDATE
, and SELECT
, as well as a DDL statement. The SQL commands may contain any functions or clauses that are allowed by Oracle SQL. AS/400 applications also can transparently access procedures and packages that are stored in an Oracle database, thereby leveraging business logic that is centralized in the Oracle server. If you have an existing application that uses the IBM CALL
command to execute an AS/400 procedure, then you can redirect this procedure to call an Oracle PL/SQL stored procedure by using the same IBM CALL
command.
Because Access Manager uses the IBM ARD interface, existing AS/400 applications that are written in C, COBOL, or RPG can directly access Oracle data. Dynamic SQL access to Oracle data is also available through the IBM DB2/400 Interactive Structured Query Language panel (STRSQL). AS/400 applications that are written using ANSI SQL might not require recompilation to access an Oracle server. Access Manager not only allows you to leverage your investment in existing AS/400 products, such as DB2/400 Query Manager and SQL Development Kit, it also provides you the opportunity to redirect AS/400 applications with little or no change to your application. Your application need not write to the proprietary Application Program Interface (API) of a vendor. You embed standard SQL statements in your AS/400 application.
AS/400 applications can now benefit from the fully distributed Oracle architecture. Access Manager allows access to data that is stored in any Oracle Database on your network. When used with Oracle Database Gateway technology, AS/400 applications also have access to over 30 non-Oracle data stores, including DB2/UDB, DB2/400 and other DB2/400 systems, VSAM, Informix, and Sybase.
Access Manager ensures that the appropriate data type conversions are performed between Oracle and AS/400. This includes support for AS/400-specific data types such as zoned decimal. Access Manager can also translate Oracle date format to the IBM AS/400 default format or to any other date format that you select.
Because Access Manager gives the AS/400 application direct access to Oracle data, downloading and uploading large quantities of data to other processors is not necessary. Instead of moving data between computers and thereby risking unsynchronized and inconsistent data, you can access data where it resides. From a single program, the AS/400 application can read AS/400 data and insert it into an Oracle database. You can also read Oracle data and insert it into DB2/400 tables.
The AS/400 system calls the Oracle Access Manager during the following operations:
During package creation, which may be initiated by any of the AS/400 CRTSQL
xxx
commands (for example, CRTSQLPKG
), the AS/400 calls Oracle Access Manager for AS/400 when the RDB parameter matches the RDB name in a relational database directory entry that is associated with the Access Manager. The AS/400 system passes SQL statement information from the user program or package. Oracle Access Manager for AS/400 can use this information to plan SQL access for the program.
However, SQL statements that are passed to Oracle Access Manager for AS/400 are currently ignored when the package is being created. If the connection fails, then the package creation also fails.
Oracle Access Manager for AS/400 is called when a CONNECT statement is issued which specifies an RDB name that matches an RDB name in an AS/400 relational database entry (RDBDIRE
) and that entry is associated with the Access Manager. Information is passed to Oracle Access Manager so that it can create an environment in which to run the subsequent SQL statements.
Oracle Access Manager for AS/400 is called during SQL processing when the current connection is to an RDB name in the relational database directory entry that is associated with the Access Manager. The AS/400 passes information about the statement being run so that Oracle Access Manager can process the statement.
DB2/400 provides support for Distributed Relational Database Architecture (DRDA) to allow an application requester to communicate with IBM application servers. In addition, Oracle application servers can be accessed by using the IBM ARD interface. Access Manager uses this interface to integrate Oracle data into your distributed database environment.
DB2/400 supports two levels of distributed databases:
A unit of work is sometimes called a transaction. A remote unit of work entails preparing and running SQL statements at only one application server during a unit of work. A distributed unit of work entails preparing and running SQL statements at multiple application servers during a unit of work. However, a single SQL statement can refer only to objects that are located at a single application server.
Oracle Access Manager supports only a distributed unit of work and extends its functionality by allowing a single statement to refer to objects located on more than one database server. For more information about distributed relational databases, refer to the appropriate IBM documentation.
A unit of work is a sequence of SQL commands that the database manager (DB2/400) treats as a single entity. The database manager ensures the consistency of data by verifying that all the data changes that are made during a unit of work are performed, or that none of them are performed. A unit of work is ended by a COMMIT
or ROLLBACK
operation.
An activation group provides the following:
All SQL connections are managed at the activation group level. The activation group and RDB name are used together to uniquely identify a connection. It is not possible to simultaneously have more than one active connection with the same RDB name in the same activation group. However, it is possible to have multiple connections with different RDB names in the same activation group and to have multiple connections with the same Oracle server through different activation groups.
The Oracle Access Manager program is created using ACTGRP(*CALLER)
. It, therefore, runs in the same activation group as the caller when it is invoked. When called from STRSQL
or by the CRTSQL
xxx
commands,Oracle Access Manager may run in the default activation group. For more information about connection management and activation groups, refer to the IBM guide for DB2/400 SQL programming.