The Programs (which include both the software and documentation) contain proprietary information; they
are provided under a license agreement containing restrictions on use and disclosure and are also protected
by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly,
or decompilation of the Programs, except to the extent required to obtain interoperability with other
independently created software or as specified by law, is prohibited.
The information contained in this document is subject to change without notice. If you find any problems in
the documentation, please report them to us in writing. This document is not warranted to be error-free.
Except as may be expressly permitted in your license agreement for these Programs, no part of these
Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose.
If the Programs are delivered to the United States Government or anyone licensing or using the Programs on
behalf of the United States Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data
delivered to U.S. Government customers are "commercial computer software" or "commercial technical data"
pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As
such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation
and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license
agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial
Computer Software--Restricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City,
CA 94065
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently
dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup,
redundancy and other measures to ensure the safe use of such applications if the Programs are used for such
purposes, and we disclaim liability for any damages caused by such use of the Programs.
Oracle, JD Edwards, PeopleSoft, and Retek are registered trademarks of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.
The Programs may provide links to Web sites and access to content, products, and services from third
parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites.
You bear all risks associated with the use of such content. If you choose to purchase any products or services
from a third party, the relationship is directly between you and the third party. Oracle is not responsible for:
(a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the
third party, including delivery of products or services and warranty obligations related to purchased
products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from
dealing with any third party.
Contents
Preface ............................................................................................................................................................... xv
Audience..................................................................................................................................................... xv
Documentation Accessibility................................................................................................................... xv
Related Documents ................................................................................................................................... xvi
Conventions ............................................................................................................................................... xvi
SQL*Plus Prompts.................................................................................................................................... xvii
DOS Prompts ............................................................................................................................................ xvii
Storage Measurements ............................................................................................................................ xvii
Directory Names....................................................................................................................................... xvii
1 Introduction
1.1Introduction to the Oracle Transparent Gateway.................................................................. 1-1
1.1.1Protection of Current Investment...................................................................................... 1-2
The Oracle Transparent Gateway for DRDA for Microsoft Windows provides users
with transparent access to DRDA databases as if they were Oracle databases.
This guide is intended for anyone responsible for installing, configuring, and
administering the gateway, and also for application developers.
Read this guide if you are responsible for tasks such as:
■Installing and configuring the Oracle Transparent Gateway for DRDA
■Setting up gateway security
■Diagnosing gateway errors
■Using the gateway to access tables in DRDA databases
■Writing applications that access DRDA databases through the gateway
■Configuring the SNA server product
You must understand the fundamentals of transparent gateways and the Microsoft
Windows operating system before using this guide to install or administer the
gateway.
Documentation Accessibility
Our goal is to make Oracle products, services, and supporting documentation
accessible, with good usability, to the disabled community. To that end, our
documentation includes features that make information available to users of assistive
technology. This documentation is available in HTML format, and contains markup to
facilitate access by the disabled community. Accessibility standards will continue to
evolve over time, and Oracle is actively engaged with other market-leading
technology vendors to address technical obstacles so that our documentation can be
accessible to all of our customers. For more information, visit the Oracle Accessibility
Program Web site at
http://www.oracle.com/accessibility/
Accessibility of Code Examples in Documentation
Screen readers may not always correctly read the code examples in this document. The
conventions for writing code require that closing braces should appear on an
otherwise empty line; however, some screen readers may not always read a line of text
that consists solely of a bracket or brace.
xv
Accessibility of Links to External Web Sites in Documentation
This documentation may contain links to Web sites of other companies or
organizations that Oracle does not own or control. Oracle neither evaluates nor makes
any representations regarding the accessibility of these Web sites.
TTY Access to Oracle Support Services
Oracle provides dedicated Text Telephone (TTY) access to Oracle Support Services
within the United States of America 24 hours a day, seven days a week. For TTY
support, call 800.446.2398.
Related Documents
The Oracle Transparent Gateway for DRDA Installation and User's Guide for Microsoft
Windows is included as part of your product. Also included is:
In this manual, "Windows" refers to any Microsoft Windows operating system.
In examples, an implied carriage return occurs at the end of each line, unless otherwise
noted. You must press the Return key at the end of a line of input.
Examples of input and output for the gateway and the Oracle environment are shown
in a special font:
> mkdir D:\ORACLE\your_name
All output is shown as it actually appears. For input, refer to the following list. The
first part of each line represents the conventions used in this manual, and the second
part describes their meanings:
... Horizontal ellipsis points in statements or commands mean that parts of the
statement or command (that are not directly related to the example) have been
omitted. Vertical ellipsis points in an example also mean that information that is not
directly related to the example has been omitted.
italic font indicates that a word or phrase of your choice must be substituted for
the term in italic font, such as your actual member name or directory name.
xvi
boldface text Boldface type in text indicates a term that is defined in the text.
< > Angle brackets enclose user-supplied names.
{ } Curly braces indicate that one of the enclosed arguments is required. Do not enter
the braces themselves.
[ ] Square brackets indicate that the enclosed arguments are optional. You can
choose one or none. Do not enter the brackets themselves.
| Vertical lines separate choices.
Other punctuation, such as commas, quotes, or the pipe symbol (|), must be entered as
shown unless otherwise specified. Directory names, file IDs, and so on, appear in
examples. When these names appear in text, they may be highlighted in bold. The use
of italics indicates that those portions of a file ID that appear in italics can vary.
SQL*Plus Prompts
The SQL*Plus prompt, SQL>, appears in SQL statements and SQL*Plus command
examples. Enter your response at the prompt. Do not enter the text of the prompt,
"SQL>", in your response.
DOS Prompts
The DOS prompt, >, appears in DOS command examples. Enter your response at
the prompt. Do not enter the text of the prompt, ">", in your response. A dollar sign
($) is part of some DOS directory names and should not be confused as a prompt
character.
Storage Measurements
Storage measurements use the following abbreviations:
■KB, for kilobyte, which equals 1,024 bytes
■MB, for megabyte, which equals 1,048,576 bytes
■GB, for gigabyte, which equals 1,073,741,824 bytes
Directory Names
Throughout this document, there are references to the directories in which
product-related files reside. ORACLE_HOME is used to represent the Oracle home
directory. This is the default location for Oracle products. If you have installed into a
location other than ORACLE_HOME, replace all references to ORACLE_HOME with
the drive and path specification you have used.
xvii
xviii
1
Introduction
The Oracle Transparent Gateway for DRDA enables you to:
■Integrate heterogeneous database management systems so that they appear as a
single homogeneous database system
■Read and write data from Oracle applications to data in DB2/OS390, DB2/400,
DB2 Universal Database, DB2/VM, and IBM SQL/DS on VM databases in
addition to any Oracle database server data.
Read this chapter for information about the architecture, uses, and features of the
Oracle Transparent Gateway for DRDA. It contains the following sections:
■Introduction to the Oracle Transparent Gateway
■Release 10g Gateways
■Gateway Capabilities
■Term s
■Architecture
■Implementation
■How the Gateway Works
■Oracle Tools and the Gateway
■Features
1.1 Introduction to the Oracle Transparent Gateway
In today’s global economy, information is a company’s most valuable resource.
Whether you need to analyze new markets, tailor your products to meet local
demands, increase your ability to handle complex customer information, or streamline
operations, your company requires instant access to current and complete information
Company growth and diversification often mean functioning with a collage of
applications and geographically scattered data that may be using incompatible
networks, platforms, and storage formats. Diverse application standards and storage
formats can make integration of information difficult. Oracle offers integration
technologies to overcome these technical barriers. Oracle Enterprise Integration
Gateways simplify complex systems and remove obstacles to information, thereby
providing your company the opportunity to focus on business.
Introduction 1-1
Release 10g Gateways
1.1.1 Protection of Current Investment
Oracle Transparent Gateway for DRDA gives your company the ability to develop its
information systems without forfeiting its investments in current data and
applications. The gateway gives you access to the Oracle and DB2 data with a single
set of applications while you continue to use existing IBM applications to access your
DB2 data. You can also use more productive database tools and move to a distributed
database technology without giving up access to the current data.
If you choose to migrate to Oracle Database technology and productivity, then the
gateway enables you to control the pace of your migration. As you transfer
applications from your previous technology to the Oracle Database, you can use the
gateway to move the DB2 data into Oracle databases.
1.2 Release 10g Gateways
Oracle Database 10g provides the foundation for the next generation of the Oracle
Enterprise Integration Gateways Release 10g, which will deliver enhanced integration
capabilities by exploiting Oracle Database 10g Heterogeneous Services. Heterogeneous
Services is a component of the Oracle Database 10g server. The Oracle Database 10g
server provides the common architecture for future generations of the gateways. For
detailed information on Oracle Heterogeneous Services, refer to Oracle Database
Heterogeneous Connectivity Administrator's Guide.
The version 10 gateways are even more tightly integrated with the Oracle
Database 10g server than previous versions, enabling improved performance and
enhanced functionality while still providing transparent integration of Oracle and
non-Oracle data. For example, connection initialization information is available in the
local Oracle Database 10g server, reducing the number of round trips and the amount
of data sent over the network. SQL processing is also faster, because statements that
are run by an application are parsed and translated once and can then be reused by
multiple applications.
Release 10g gateways leverage any enhancements in the Oracle Database 10g server,
and you can quickly extend those benefits to the non-Oracle data.
1.2.1 Advantages of the Gateway
Oracle Transparent Gateway for DRDA enables Oracle applications to access the
DRDA Application Servers, such as DB2 for OS/390 (MVS), through Structured Query
Language (SQL). The gateway and the Oracle Database 10g server together create the
appearance that all data resides on a local Oracle Database 10g server, though data
might be widely distributed. If data is moved from a DRDA Application Server
database to an Oracle Database server, then no changes in application design or
function are needed. The gateway handles all differences in both data types and SQL
functions between the application and the database.
1.3 Gateway Capabilities
Oracle Transparent Gateway for DRDA gives you the power to integrate your
heterogeneous systems into a single, seamless environment. This integration enables
you to make full use of existing hardware and applications throughout your
corporatewide environment. You can eliminate the need to rewrite applications for
each configuration, and you can avoid the tedious, error-prone process of manual data
transfer. Together with the Oracle tools, networking, and data server technology, the
Oracle Transparent Gateway for DRDA sets a high standard for seamless, enterprise
wide information access.
1-2 Oracle Transparent Gateway for DRDA Installation and User's Guide
Oracle Transparent Gateway for DRDA enables applications to read and update DB2
data and Oracle data as if all of the data were stored in a single database. As a result,
users and application programmers are not required to know either the physical
location or the storage characteristics of the data. This transparency not only permits
you to integrate heterogeneous data seamlessly, but also simplifies your gateway
implementation, application development, and maintenance.
1.3.1 Transparency at All Levels
The Oracle Transparent Gateway for DRDA gives you transparency at every level
within your enterprise.
■Location transparency
Users can access tables by name without needing to understand the physical
location of the tables.
■Network transparency
The gateways exploit Oracle Net technology to enable users to access data across
multiple networks without concern for the network architecture or protocols.
TCP/IP protocol is supported.
■Operating system transparency
Gateway Capabilities
You can access data that is stored under multiple operating systems without being
aware of the operating systems that hold the data.
■Data storage transparency
Data can be accessed regardless of the database or file format.
■Access method transparency
You can use a single dialect of SQL for any data store, eliminating the need to code
for database-specific access methods or SQL implementations.
1.3.2 Extended Database Services
Following are some of the more sophisticated Oracle Database 10g server services that
are available through the gateway.
■SQL functions
Your application can access all of your data using Oracle SQL, which is rich in
features. Advanced Oracle Database 10g server functions, such as outer joins, are
available even if the target data stores do not support them in a native
environment. The method by which the gateways are integrated with the Oracle
Database 10g server ensures that the newest features of each database release are
always available immediately to the gateway.
■Distributed capabilities
Heterogeneous data can be integrated seamlessly because Oracle Database
distributed capabilities, such as JOIN and UNION, can be applied to non-Oracle
data without any special programming or mapping.
■Distributed query optimization
The Oracle Database 10g server can use its advanced query optimization
techniques to ensure that SQL statements are run efficiently against any of your
data. The data distribution and storage characteristics of local and remote data are
equally considered.
Introduction 1-3
Gateway Capabilities
■Two-phase commit protection
The Oracle server two-phase commit mechanism provides consistency across data
stores by ensuring that a transaction that spans data stores is still treated as a
single unit of work. Changes are not committed (or permanently stored) in any
data store unless the changes can be committed in all data stores that will be
affected.
■ Stored procedures and database triggers
The same Oracle stored procedures and database triggers can be used to access all
of the data, thereby ensuring uniform enforcement of business rules across the
enterprise.
1.3.3 Extended Advanced Networking, Internet and Intranet Support
The gateway integration with the Oracle Database 10g server extends (to non-Oracle
data) the benefits of the Oracle Internet software, and Oracle Net software and extends
the benefits of the Oracle client/server and server/server connectivity software. These
powerful features include:
■Application server support
Any Internet or intranet application that can access data in Oracle database can
also incorporate information from data stores that are accessible through the
gateways. Web browsers can connect to Oracle database using any application
server product that supports Oracle software.
■Implicit protocol conversion
Oracle Database and Oracle Net can work together as a protocol converter,
enabling applications to transparently access other data stores on platforms that
do not support the network protocol of the client. An Oracle Database 10g server
can use TCP/IP to communicate with the gateway and another data store.
■Advanced Security
Non-Oracle data can be protected from unauthorized access or tampering during
transmission to the client. This is done by using the hardware-independent and
protocol-independent encryption and CHECKSUM services of Advanced Security.
■Wireless communication
Oracle Mobile Agents, an industry-leading Oracle mobile technology, enables
wireless communication to Oracle Database 10g servers or to any databases that
are accessible through the gateways. This gives your field personnel direct access
to enterprise data from mobile laptop computers.
1.3.4 Dynamic Dictionary Mapping
The simple setup of the gateway does not require any additional mapping. Before an
application can access any information, the application must be told the structure of
the data, such as the columns of a table and their lengths. Many products require
administrators to manually define that information in a separate data dictionary
stored in a hub. Applications then access the information using the hub dictionary
instead of the native dictionaries of each database. This approach requires a great deal
of manual configuration and maintenance on your part. As administrators, you must
update the data dictionary in the hub whenever the structure of a remote table is
changed.
1-4 Oracle Transparent Gateway for DRDA Installation and User's Guide
Inefficient duplication is not necessary with Oracle Transparent Gateway for DRDA.
The gateway uses the existing native dictionaries of each database. The applications
access data using the dictionaries that are designed specifically for each database,
which means that no redundant dictionary ever needs to be created or maintained.
1.3.5 SQL
Oracle Transparent Gateways ease application development and maintenance by
enabling you to access any data using a uniform set of SQL queries. Changes to the
location, storage characteristics, or table structure do not require any changes to the
applications. ANSI and ISO standard SQL are supported, along with powerful Oracle
extensions.
1.3.6 Data Definition Language
Oracle applications can create tables in target data stores by using native data
definition language (DDL) statements.
1.3.7 Data Control Language
You can run native data control language (DCL) statements from an Oracle
environment, enabling central administration of user privileges and access levels for
heterogeneous data stores.
Gateway Capabilities
1.3.8 Passthrough and Native DB2 SQL
Running of native DB2 SQL can be passed through the gateway for processing directly
against DB2. This enables applications to send statements, such as a DB2 CREATE TABLE, to the gateway for running on a target DB2 system.
1.3.9 Stored Procedures
The gateway enables you to exploit both Oracle and non-Oracle stored procedures,
leveraging your investments in a distributed, multi database environment. Oracle
stored procedures can access multiple data stores easily, without any special coding
for heterogeneous data access.
1.3.9.1 Oracle Stored Procedures
Oracle stored procedures enable you to access and update DB2 data by using
centralized business rules that are stored in the Oracle Database 10g server. Using
Oracle stored procedures can increase database performance by minimizing network
traffic. Instead of sending individual SQL statements across the network, an
application can send a single EXECUTE command to begin an entire PL/SQL routine.
1.3.9.2 Native DB2 Stored Procedures
The gateway can run DB2 stored procedures using standard Oracle PL/SQL. The
Oracle application run the DB2 stored procedure as if it were an Oracle remote
procedure.
1.3.10 Languages
Any application or tool that supports the Oracle Database 10g server can access over
thirty different data sources through the Oracle gateways. A wide variety of open
system tools from Oracle and third-party vendors can be used, even if the data is
Introduction 1-5
Gateway Capabilities
stored in legacy, proprietary formats. Hundreds of tools are supported, including ad
hoc query tools, Web browsers, turnkey applications, and application development
tools.
1.3.11 Oracle Database Server Technology and Tools
The gateway is integrated into the Oracle Database server technology, which provides
global query optimization, transaction coordination for multisite transactions, support
for all Oracle Net configurations, and so on. Tools and applications that support the
Oracle Database server can be used to access heterogeneous data through the gateway.
1.3.12 SQL*Plus
You can use SQL*Plus for moving data between databases. This product gives you the
ability to copy data from your department databases to corporate Oracle databases.
1.3.13 Two-Phase Commit and Multisite Transactions
The gateway can participate as a partner in multisite transactions and two-phase
commit. How this occurs depends on the capabilities of the underlying data source,
meaning that the gateway can be implemented as any one of the following:
■A full two-phase commit partner
■A commit point site
■A single-site update partner
■A read-only partner
The deciding factors for the implementation of the gateway are the locking and
transaction-handling capabilities of the target database.
Oracle Transparent Gateway for DRDA, by default, is configured as a commit point
site (that is, commit confirm protocol). Optionally, you can configure the gateway as
read-only if you choose to enforce read-only capability through the gateway. Other
protocols are not supported. Refer to "Read-Only Gateway" on page 11-5 in
Chapter 11, "Using the Gateway".
1.3.14 Site Autonomy
All Oracle Database server products, including gateways, supply site autonomy. For
example, administration of a data source remains the responsibility of the original
system administrator. Site autonomy also functions so that gateway products do not
override the security measures that are established by the data source or the operating
environment.
1.3.15 Migration and Coexistence
The integration of a data source through the gateway does not require any changes to
be made to applications at the data source. The result is that the Oracle Database
server technology is nonintrusive, providing coexistence and an easy migration path.
1.3.16 Security
The gateway does not bypass existing security mechanisms. Gateway security coexists
with the security mechanisms that are already used in the operating environment of
the data source.
1-6 Oracle Transparent Gateway for DRDA Installation and User's Guide
1.4 Terms
Architecture
Functionally, gateway security is identical to that of an Oracle Database server, as
described in the Oracle Database Administrator's Guide. Oracle Database security is
mapped to the data dictionary of the data source.
The terms that are used in this guide do not necessarily conform to IBM terminology.
The following table presents several terms and their meanings as used within this
guide:
TermsMeaning
DRDA dataAny database data that is accessed through DRDA
DRDA databaseThe collection of data that belongs to a DRDA Server
DRDA ServerA database server that can be accessed through DRDA. IBM
terminology for a DRDA Server is a DRDA Application Server,
or AS.
DRDA server typeA specific database product or program that can act as a DRDA
Oracle integrating serverAny Oracle Database 10g server instance that communicates
DB2 Universal DatabaseA generic name for the UNIX-based implementations of DB2.
1.5 Architecture
The Oracle Transparent Gateway for DRDA works with the Oracle Database 10g
server to shield most of the differences of the non-Oracle database from Oracle
applications. This means that the Oracle applications can access the Oracle
Database 10g server data and also can access the DRDA database data as if it were
Oracle data located at the Oracle integrating server.
The architecture consists of the following main components:
■Client
The client is an Oracle application or tool.
■Oracle integrating server
server
with the Oracle Transparent Gateway for DRDA to distribute
database access operations to a DRDA Server. The Oracle
integrating server can also be used for non-gateway
applications.
DB2/UDB is frequently used as an abbreviation for DB2
Universal Database.
The Oracle integrating server is an Oracle Database instance that is accessed by an
Oracle Database 10g server with procedural and distributed options. Usually, the
Oracle integrating server is installed on the same host as the gateway, but this is
not a requirement. The Oracle integrating server and the gateway communicate in
the normal Oracle server-to-server manner.
If the Oracle integrating server is not on the host where the gateway resides, then
you must install the correct Oracle networking software on the platform where the
server resides. For Oracle Database 10g, you must install Oracle Net on the Oracle
Database 10g server system.
■Oracle Transparent Gateway for DRDA
Introduction 1-7
Implementation
The gateway must be installed on hosts that are running the appropriate operating
system.
If the Oracle integrating server is not on the same host, then you must also install
Oracle Net so that the gateway and Oracle Database 10g server can communicate.
■DRDA Server
The DRDA Server must be a DB2/OS390, DB2/400, DB2 Universal Database, or
DB2 server for VM database on a system that is accessible to the host using either
the SNA or TCP/IP protocol.
Multiple Oracle Database 10g servers can access the same gateway. A single host
gateway installation can be configured to access more than one DRDA Server.
Figure 1–1 illustrates the gateway architecture that was just described.
Figure 1–1 The Gateway Architecture
Client
1.6 Implementation
When the gateway is installed on your host, it has some of the same components as an
Oracle Database instance on Microsoft Windows. The gateway has the following
components:
■A base file directory, similar to the one that is associated with the
ORACLE_HOME environment variable of an Oracle Database instance
■A gateway system identifier (SID), comparable to the ORACLE_SID of an Oracle
Database instance
■Oracle Net to support communication between the Oracle integrating server and
the Oracle Transparent Gateway for DRDA
Oracle Net
or
Local
Connection
Oracle
Integrating
Server
Oracle
Transparent
Gateway for
DRDA
Oracle
Transparent
Gateway for
DRDA
SNA
TCP/IP
DARD
Server
DARD
Server
The gateway does not have:
■Control, redo log, or database files
■The full set of subdirectories and ancillary files that are associated with an
installed Oracle Database 10g server
Because the gateway does not have background processes and does not need a
management utility such as Oracle Enterprise Manager, you do not need to start the
gateway product. Each Oracle Database 10g server user session that accesses a
particular gateway creates an independent process on the host. This process runs the
gateway session and runs SNA or TCP/IP functions to communicate with a DRDA
Server.
1-8 Oracle Transparent Gateway for DRDA Installation and User's Guide
1.7 How the Gateway Works
The gateway has no database functions of its own. Instead, it provides an interface by
which an Oracle Database 10g server can direct part or all of a SQL operation to a
DRDA database.
The gateway that is supporting the DRDA Server is identified to the Oracle integrating
server by using a database link. The database link is the same construct that is used to
identify other Oracle Database 10g server databases. Tables on the DRDA Server are
referenced in SQL as:
table_name@dblink_name
or
owner.table_name@dblink_name
If you create synonyms or views in the Oracle integrating server database, then you
can refer to tables on the DRDA Server by using simple names as though the table
were local to the Oracle integrating server.
When the Oracle integrating server encounters a reference to a table that is on the
DRDA Server, the applicable portion of the SQL statement is sent to the gateway for
processing. Any host variables that are associated with the SQL statement are bound
to the gateway and, therefore, to the DRDA Server.
Oracle Tools and the Gateway
The gateway is responsible for sending these SQL statements to the DRDA Server for
processing and for fielding and is also responsible for returning responses. The
responses are either data or messages. Any conversions between Oracle data types and
DRDA data types are performed by the gateway. The Oracle integrating server and
the application read and process only Oracle data types.
1.7.1 SQL Differences
Not all SQL implementations are the same. The Oracle Database 10g server supports a
larger set of built-in functions than the databases that are currently accessed through
the gateway. The Oracle integrating server and the gateway work together to convert
SQL to a form that is compatible with the specific DRDA Server.
During this conversion, an Oracle Database 10g server function can be converted to a
function that is recognizable to the specific DRDA Server. For example, the Oracle
Database 10g server NVL function is converted to the DB2 VALUE function.
Alternatively, the Oracle integrating server withholds functions that are not executable
by the DRDA Server, and it performs them after rows are fetched from the DRDA
database. This processing generally applies to SELECT statements. The Oracle
integrating server and the gateway cannot perform this kind of manipulation on
UPDATE, INSERT, or DELETE statements because doing so changes transaction
semantics.
1.8 Oracle Tools and the Gateway
Use the gateway to run applications, such as Oracle tools, that read and write data that
is stored in DRDA databases.
Although the Oracle Transparent Gateway for DRDA provides no new application or
development facilities, it extends the reach of existing Oracle tools to include data in
non-Oracle databases that support DRDA.
Introduction 1-9
Features
Using the Oracle Transparent Gateway for DRDA with other Oracle products can
greatly extend the capabilities of the standalone gateway. The following examples
demonstrate how powerful the gateway is with other Oracle tools.
1.8.1 SQL*Plus
Use SQL*Plus and the Oracle Transparent Gateway for DRDA to create a distributed
database system, providing an easy-to-use transfer facility for moving data between
the distributed databases. One possible use is to distribute the data in your corporate
Oracle Database to departmental DRDA databases. You can also distribute data in
your corporate DRDA database to departmental Oracle Databases.
1.9 Features
Following is a list of important features that characterize this release of the gateway.
1.9.1 Heterogeneous Services Architecture
This release of the Oracle Transparent Gateway for DRDA uses the Oracle
Heterogeneous Services component within the Oracle Database 10g server.
Heterogeneous Services is the building block for the next generation of Oracle
Enterprise Integration Gateways.
For detailed information about Heterogeneous Services, refer to the Oracle Database Heterogeneous Connectivity Administrator's Guide.
1.9.2 Performance Enhancements
Oracle Transparent Gateway for DRDA contains several internal performance
enhancements. This product has shown major improvements in response time and
CPU utilization for all relevant address spaces for a variety of workloads compared to
version 9 gateways. The actual performance improvement at your site might vary,
depending on your installation type and workload.
1.9.3 Fetch Reblocking
The array size of the application for SELECT is effective between the application and
the Oracle integrating server. However, the array block size and the block fetch
between the Oracle integrating server and the gateway are controlled by two
Heterogeneous Services initialization parameters, HS_RPC_FETCH_SIZE and
HS_RPC_FETCH_REBLOCKING. These parameters are specified in the gateway
initialization file. Refer to the Oracle Database Heterogeneous Connectivity Administrator's Guide for more information.
1.9.4 Oracle Database 10g Passthrough Supported
You can use the Oracle Database 10g DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATE feature to pass commands or
statements (that are available in the DRDA database) through the gateway.
1.9.5 Retrieving Result Sets Through Passthrough
Oracle Transparent Gateway for DRDA provides a facility to retrieve result sets from a
select SQL statement that is run with passthrough. Refer to "Retrieving Result Sets
Through Passthrough" on page 12-27 for additional information.
1-10 Oracle Transparent Gateway for DRDA Installation and User's Guide
1.9.6 Support for TCP/IP
This release of the gateway supports the TCP/IP communication protocol between the
gateway and the DRDA Server. Refer to Chapter 8, "Configuring TCP/IP" for further
information.
1.9.7 Native Semantics
This release of the gateway supports the ability to selectively enable or disable
post-processing of various SQL functions by the DRDA Server. Refer to "Native
Semantics" on page 12-18 for further information.
1.9.8 Columns Supported in a Result Set
Oracle Transparent Gateway for DRDA supports up to 1000 columns in a result set.
1.9.9 EXPLAIN_PLAN Improvement
The EXPLAIN_PLAN table contains the actual SQL statements passed to the DRDA
Server from the Oracle Database 10g server through the gateway.
1.9.10 Heterogeneous Database Integration
The gateway support for ANSI-standard SQL enables read/write access to DRDA
databases. Even if your data exists on different platforms in different applications,
new applications can use all data, regardless of location.
Features
1.9.11 Minimum Impact on Existing Systems
The gateway does not require installation of additional Oracle software on your
OS/390 (MVS), AS/400, VM, UNIX or Microsoft Windows target system. The database
interface that it uses is provided by IBM and is built into the DRDA database products
and SNA or TCP/IP facilities that already exist on these platforms.
Configuring an IBM system for DRDA access typically consists of defining the SNA or
TCP/IP resources involved and establishing access security definitions specific to the
target database.
1.9.12 Large Base of Data Access
DRDA Application Server Function is supported by most IBM DB2 database products.
1.9.13 Application Portability
The ability of the gateway to interface with heterogeneous databases makes it possible
to develop a single set of portable applications that can be used against both Oracle
and IBM databases, and any other databases for which Oracle Corporation provides
gateways.
1.9.14 Remote Data Access
Location flexibility is maximized because the gateway architecture permits network
connections between each of the components. The application can use the Oracle
client-server capability to connect to a remote Oracle integrating server through Oracle
Net. The Oracle integrating server can connect to a remote gateway using a database
Introduction 1-11
Features
link. The gateway connects to DRDA Servers through SNA or TCP/IP network
facilities.
The benefits of remote access are that it:
■Provides a means to allocate the suitable resource to a given task
You can, for example, move application development off expensive processors
and onto cost-efficient workstations or microcomputers.
■Expands the number of available data sources
Without remote access, you are limited to the data that is available in the local
environment. With remote access, your data sources are limited only by your
networks.
■Provides a means to tailor an application environment to a given user
For example, some users prefer a block-mode terminal environment, while others
prefer a bit-mapped, graphics-driven terminal environment. Remote access can
satisfy both because you are not constrained by the interface environment that is
imposed by the location of your data.
1.9.15 Support for Distributed Applications
Because the gateway gives your application direct access to DRDA data, you eliminate
the need to upload and download large quantities of database data to other
processors. Instead, you can access data where it is, when you want it, without having
to move the data between systems and thus risk unsynchronized and inconsistent
data. Avoiding massive data replication can also reduce aggregate disk storage
requirements over all of your systems.
However, if your system design requires moving data among the systems in a
network, SQL*Plus and the gateway can simplify the data transfer. With a single
SQL*Plus command, you can move entire sets of data from one node of the network to
another and from one database to another.
You can pass commands and statements that are specific to your DRDA database
through the gateway to be run by the DRDA database. For example, you can pass
DB2/OS390 commands through the gateway for DB2 to run. You can also run stored
procedures defined in non-Oracle databases.
1.9.16 Application Development and End User Tools
Through the gateway, Oracle extends the range of application development and user
tools that you can use to access the IBM databases. These tools increase application
development and user productivity by reducing prototype, development, and
maintenance time. Current Oracle users do not have to learn a new set of tools to
access data that is stored in DRDA databases. Instead, they can access Oracle and
DRDA data with a single set of tools.
With the gateway and the application development tools that are available from
Oracle, you can develop a single set of applications to access Oracle data and DRDA
data. Users can use the decision support tools that are available from Oracle to access
Oracle data and DRDA data. These tools can run on remote systems that are connected
through Oracle Net to the Oracle integrating server.
When designing applications, keep in mind that the gateway is designed for retrieval
and relatively light transaction loads. The gateway is not currently designed to be a
heavy transaction processing system.
1-12 Oracle Transparent Gateway for DRDA Installation and User's Guide
1.9.17 Password Encryption Utility
This release of the gateway includes a utility to support encryption of plain-text
passwords in the gateway initialization file. Refer to Chapter 13, "Security
Considerations" for details.
1.9.18 Support for DB2/OS390 V6, V7, and V8 Stored Procedures
This release of the gateway supports the native stored procedure catalogs in DB2 V6,
V7, and V8 (SYSIBM.SYSROUTINES and SYSIBM.SYSPARMS).
1.9.19 Codepage Map Facility
This release of the gateway supports external mapping of IBM CCSIDs to Oracle
character sets. Refer to "Gateway Codepage Map Facility" on page D-5 in Appendix D,
"National Language Support".
1.9.20 IBM DB2 Universal Database Support
This release supports IBM DB2 Universal Database.
1.9.21 IBM DB2 Version 5.1 ASCII Tables
IBM DB2 version 5.1 supports ASCII and EBCDIC character sets. The character set
selection is defined during table creation. The Oracle Transparent Gateway for DRDA
supports access to EBCDIC tables and ASCII tables. Refer to Appendix D, "National
Language Support".
Features
1.9.22 Read-Only Support
This release enables the gateway to be configured as a read-only gateway. In this
mode, no modifying of user data is permitted. For more information, refer to
"DRDA_READ_ONLY" on page C-8.
1.9.23 Support for Graphic and Multibyte Data
This release of the gateway adds support for DB2 GRAPHIC and VARGRAPHIC data
types. Refer to Chapter 12, "Developing Applications".
1.9.24 Support for DB2/UDB on Intel Hardware
This release of the gateway adds support for DRDA Servers running on Microsoft
Windows and Linux on Intel hardware.
1.9.25 Data Dictionary Support for DB2/UDB
This release of the gateway adds Oracle data dictionary support for DB2 UDB V7.
Refer to "Sample SQL scripts" for more information.
Introduction 1-13
Features
1-14 Oracle Transparent Gateway for DRDA Installation and User's Guide
This chapter provides information specific to this release of the Oracle Transparent
Gateway for DRDA. It includes the following sections:
■Product Set
■Changes and Enhancements
■Bugs Fixed in 10g Release 2 (10.2)
■Known Problems
■Known Restrictions
2.1 Product Set
The following is a list of the production components that are included in the product
CD-ROM:
2
Release Information
■Oracle Transparent Gateway for DRDA, Release 10.1.0.2.0
■Oracle Net, release 10.2.1.0
2.2 Changes and Enhancements
Following is a list of changes and enhancements that are unique to this release of the
gateway.
Gateway Password Encryption Tool
The Gateway Password Encryption tool (g4drpwd) has been replaced by a generic
feature which is now part of Heterogenous Services. Refer to Chapter 13, "Security
Considerations" for more information.
Product Migration
Refer Chapter 14, "Migration and Coexistence with Existing Gateways" for information
about migrating product configurations from previous releases for additional changes
or requirements.
2.3 Bugs Fixed in 10g Release 2 (10.2)
4013463
GARBAGES CONTAINED IN ERROR MESSAGE FROM TG4DRDA
Release Information 2-1
Bugs Fixed in 10g Release 2 (10.2)
3882675
TG4DRDA SELECT FOR UPDATE ERROR WITH G4DRSRVD
3650803
MEMORY LEAK IN G4DRSRV DOING SELECT STATEMENT
3640384
ORA-28500 ON SELECT FOR UPDATE FROM TG4DRDA
3610131
INDEX STATS MAY NOT BE QUERIED CORRECTLY
3514233
SETTING DRDA_OPTIMIZE_QUERY=TRUE DOES NOT GENERATE TABLE STATS
3429017
LINKING ERROR FOR G4DRSRV WHEN USING REDHAT AS V3
3421215
IU GUIDE DIDN'T SAY HOW TO CONFIG DRDA_CONNECT_PARM IN LINUX
3287626
ENGLISH NAME OF "TAIWAN" DOESN'T SEEM TO BE APPROPRIATE
3143686
QA - 10G - CAN NOT SELECT FROM DATA DICTIONARY TABLES
4218317
COUNT(COLNAME) NOT TRANSLATED TO COUNT(*)
4260112
ORA-1001 WITHOUT THE DETAIL RETURNS FROM TG4DRDA
4065600
GARBAGES CONTAINED IN ORA-1 ERROR MESSAGE FROM TG4DRDA
3965425
ORA-07445 [_MEMCPY()+772] REPEATABLE READ ISOLATION LEVEL IS NOT
WORKING
3709345
PSR 9.2.0.5.0 BREAKS CALL DB2 STORED PROCEDURE WITH DECIMAL PARM.
SQLCODE -310
3130329
TG4DRDA LOOPS IF QRWTSRVR JOB KILLED WHILE GATEWAY IS IN GDJCRCV
2-2 Oracle Transparent Gateway for DRDA Installation and User's Guide
2.4 Known Problems
The problems that are documented in the following section are specific to the Oracle
Transparent Gateway for DRDA and are known to exist in this release of the product.
These problems will be fixed in a future gateway release. If you have any questions or
concerns about these problems, then contact Oracle Support Services.
A current list of problems is available online. Contact your local Oracle office for
information about accessing this online information.
2.5 Known Restrictions
The following restrictions are known to exist for the products in this release.
Restrictions are not scheduled to change in future releases. Also refer to Chapter 12,
"Developing Applications", for information about limitations when developing your
applications.
Accessing DB2 Alias Objects
If you need to access DB2 alias objects on a remote DB2 system, then you must specify
DRDA_DESCRIBE_TABLE=FALSE initialization parameter in the gateway initialization
file.
Known Restrictions
Oracle SQL Command INSERT
When copying data from an Oracle server to a DRDA Server, the Oracle SQL
command INSERT is not supported. The SQL*Plus COPY command must be used.
Refer to Chapter 11, "Using the Gateway", for more information.
2.5.1 DB2 Considerations
DD Basic Tables and Views
The owner of DD basic tables and views is OTGDB2. This cannot be changed.
SUBSTR Function Post-Processed
The SUBSTR function can be used with the Oracle Server in ways that are not
compatible with a DRDA Server database such as DB2/OS390. Therefore, the SUBSTR
function is post-processed. However, it is possible to enable the server to process it
natively using the "Native Semantics" feature. Refer to Chapter 12, "Developing
Applications", for details.
AVS Mapping User IDs (DB2/VM)
APPC VTAM Support (AVS) has problems mapping user IDs that are sent using
lowercase letters or special characters. Contact your IBM representative for additional
information about this problem.
Support for DRDA Server Character Sets
Support (for character sets that are used by a DRDA Server) is configurable through
the gateway Codepage Map Facility. Refer to Appendix D, "National Language
Support" for more information.
data type Limitations
Refer to "DRDA Data Type to Oracle Data Type Conversion" on page 12-20 for detailed
information about data types.
Release Information 2-3
Known Restrictions
SAVEPOINT Command Is Not Supported
Oracle Transparent Gateway for DRDA does not support the Oracle command
SAVEPOINT.
Null Values and Stored Procedures
Null values are not passed into, or returned from, calls to stored procedures through
the gateway.
String Concatenation of Numbers
String concatenation of numbers is not permitted in DB2/400, DB2/UDB, and
DB2/OS390. For example, 2||2 is not permitted.
GLOBAL_NAMES Initialization Parameter
If GLOBAL_NAMES is set to TRUE in the Oracle server INIT.ORA file, then to be able
to connect to the gateway, you must specify the Heterogeneous Services (HS)
initialization parameters, HS_DB_DOMAIN and HS_DB_NAME, in the Gateway
Initialization Parameter file to match the value of the Oracle server DB_DOMAIN
parameter. Refer to Chapter 10, "Configuring the Gateway", for more information.
Binding the DRDA Package on DB2/UDB
The DRDA gateway package must be bound on the DRDA Server before the gateway
can perform any SQL operations. Because of a DB2/UDB restriction, the ORACLE2PC
table must be created in the DB2/UDB database before the package can be bound. For
details, refer to Chapter 10, "Configuring the Gateway".
Date Arithmetic
In general, the following types of SQL expression forms do not work correctly with the
gateway because of DRDA Server limitations:
date + number
number + date
date - number
date1 - date2
DRDA Servers do not permit number addition or subtraction with date data types.
The date and number addition and subtraction (date + number, number + date, date - number) forms are sent through to the DRDA Server where they are
rejected.
Also, DRDA Servers do not perform date subtraction consistently. When you subtract
two dates (date1 - date2), differing interpretations of date subtraction in the
DRDA Servers cause the results to vary by server.
Note: Avoid date arithmetic expressions in all gateway SQL until
date arithmetic problems are resolved.
Row Length Limitation
Because of a restriction of the DRDA architecture, rows with aggregate length
exceeding 32 K bytes in DRDA representation cannot be stored or retrieved.
LONG data type in SQL*Plus
SQL*Plus cannot fetch LONG columns from the Oracle Transparent Gateway for
DRDA.
2-4 Oracle Transparent Gateway for DRDA Installation and User's Guide
Known Restrictions
Dictionary Views Are Not Provided for DB2/VM
Currently, the Oracle Transparent Gateway for DRDA provides SQL for defining
DB2/OS390, DB2/400, and DB2/UDB views that emulate parts of the Oracle Database
dictionary. These are required for certain applications and tools that query dictionary
tables. View definitions for DB2/VM are not provided in this release.
Single Gateway Instance per DRDA Network Interface
When installing the gateway, a proper DRDA network interface must be chosen. Only
one DRDA network interface may be chosen and installed per gateway instance. If the
gateway product is reinstalled, and if a network interface different from the previous
installation is chosen, then the new choice will overlay the current installation.
Reconfiguration of the gateway's initialization parameters must occur at this point to
ensure proper gateway operation. If you want to have both SNA and TCP/IP DRDA
Network Interfaces installed, then you must install two separate gateway homes.
Stored Procedures and transaction integrity
IBM DB2 has introduced a feature called Commit on Return for stored procedures.
This feature enables DB2 to perform an automatic commit after a stored procedure
runs successfully. This feature is enabled when the procedure is created. To ensure
data integrity, this feature is not supported by the Oracle Transparent Gateway for
DRDA in a heterogeneous environment. When attempting to call a stored procedure
which has this feature enabled, through the gateway, the gateway will return an error
message ORA-28526 or PLS-00201 (identifier must be declared).
Stored Procedure and User Defined Function Support
The gateway supports processing of stored procedures and user defined functions
through the following DRDA Servers:
DB2/OS390 V4.1 or later
DB2/400 V3.1 or later
DB2/UDB V7.1 or later
2.5.2 SQL Limitations
Oracle ROWID Column
The DB2 ROWID column is not compatible with the Oracle ROWID column. Because
the ROWID column is not supported, the following restrictions apply:
■UPDATE and DELETE are not supported with the WHERE CURRENT OF CURSOR
clause. To update or delete a specific row through the gateway, a condition style
WHERE clause must be used. (Bug No. 205538)
When UPDATE and DELETE statements are used, in precompiler and PL/SQL
programs, they rely internally on the Oracle ROWID function.
Note: This restriction applies to DB2 for MVS or z/OS as of v5.1
and DB2/UDB as of v8.1.
■Snapshots between Oracle servers and DB2 are not supported.
Snapshots rely internally on the Oracle ROWID column.
Release Information 2-5
Known Restrictions
Oracle Bind Variables
Oracle bind variables become SQL parameter markers when used with the gateway.
Therefore, the bind variables are subject to the same restrictions as SQL parameter
markers.
For example, the following statements are not permitted:
WHERE :x IS NULL
WHERE :x = :y
CONNECT BY Is Not Supported
Oracle Transparent Gateway for DRDA does not support CONNECT BY in SELECT
statements.
COUNT Function Compatibility
The following DRDA server releases do not support all forms of the COUNT function,
specifically COUNT(colname) and COUNT(ALL colnames):
DB2 OS/390 V6,
DB2/VM V6 and V7
The default for all DRDA server platforms (except DB2/VM) is for all forms of COUNT
to be passed to the DRDA server as it is. For DB2/VM, the forms COUNT(colname)
and COUNT(ALL colname) have been disabled by default and will be
post-processed.
If the gateway is to be used with one of the above releases of DRDA servers, then it
may be necessary to disable the default usage of this form of COUNT.
Refer to Section 12.7.9, "Mapping the COUNT Function" and Section 12.6, "Native
Semantics" for details on how to disable or enable compatibility for these forms of
COUNT function.
2-6 Oracle Transparent Gateway for DRDA Installation and User's Guide
This chapter provides information about hardware and software requirements that is
specific to this release of the Oracle Transparent Gateway for DRDA. This chapter
includes the following sections:
■Hardware Requirements
■Software Requirements
■Documentation Requirements
3.1 Hardware Requirements
The following are the minimum hardware requirements for the Oracle Transparent
Gateway for DRDA on Microsoft Windows.
3.1.1 Processor
This gateway requires a host with an Intel or 100% compatible PC with a
Pentium-based processor that can run the required version of Microsoft Windows.
Refer to the Oracle Database Installation Guide for Microsoft Windows (32-Bit) and to the
certification matrix on Oracle MetaLink for the most up-to-date list of certified
hardware platforms and operating system version requirements to operate the
gateway for the system. The Oracle MetaLink web site can be found at the following
URL:
3
System Requirements
3.1.2 Memory
http://metalink.oracle.com/
For this release, 64 MB of real memory is the recommended minimum for running one
instance of the gateway. Running additional instances of the Oracle Transparent
Gateway for DRDA might require additional real memory or increased swap space to
achieve reasonable performance.
The total real memory requirement for each concurrent use of the gateway depends on
the following factors:
■Number of concurrent APPC connections opened by each user
■Number of concurrent TCP/IP connections opened by each user
■Number of data items being transferred between the gateway and the remote
transaction program
System Requirements 3-1
Software Requirements
■Additional factors such as configured network buffer size
3.1.3 Network Attachment
The hardware requires any network attachment supported by either Microsoft SNA
Server for SNA communication or Microsoft Windows Sockets for TCP/IP
communication. The network attachment for SNA is typically a Token Ring or SDLC
Coaxial attachment. The hardware must support independent LUs if you want
concurrent SNA access. The network attachment for TCP/IP is typically an Ethernet
attachment.
3.1.4 Disk Space
260 MB of disk space is required for installation.
3.2 Software Requirements
The system software configuration described in these requirements is supported by
Oracle as long as the underlying system software products are supported by their
respective vendors. Verify the latest support status with your system software
vendors.
3.2.1 Operating System
The Oracle Transparent Gateway for DRDA will run on the following operating
systems:
■Microsoft Windows NT Server, version 4.0 (with Service Pack 6 or later)
■Microsoft Windows NT Workstation, version 4.0 (with Service Pack 6 or later)
■Microsoft Windows 2000 Server (with Service Pack 2 or later)
■Microsoft Windows 2000 Professional (with Service Pack 2 or later)
■Microsoft Windows 2003 Server
■Microsoft Windows XP Professional
Refer to the certification matrix on Oracle MetaLink for the most up-to-date list of
certified hardware platforms and operating system version requirements to operate
the gateway for your system. The Oracle MetaLink Web site can be found at the
following URL:
http://metalink.oracle.com/
3.2.2 DRDA Databases
You must have at least one of the following DRDA servers at a supported release level:
■DB2/OS390
■DB2/VM
■DB2/400
■DB2/Universal Database
3-2 Oracle Transparent Gateway for DRDA Installation and User's Guide
3.2.3 Communications
Supported SNA network software are:
■Microsoft SNA Server or Client, version 3.0 or version 4.0, or Host Integration
Server, Version 5.0
■IBM Communications Server, Version 5.0 or 6.0
Note: Version 5.0 requires the following patches:
■JR12583 (Super fix)
■JR12539 (individual Local LUs fix)
3.2.4 Oracle Database server
The Oracle Database server which is to act as the Oracle integrating server requires the
latest released patch set for Oracle Database 10g server release 10.2, 10.1, or Oracle9i
server release 9.2.
3.2.5 Oracle Networking Products
If the Oracle integrating server is not on the same host as the gateway, then Oracle Net
is required to support communication between the Pentium-based host and the Oracle
integrating server.
Documentation Requirements
The following Oracle networking products are required on the same system as the
Oracle Database 10g server:
■Oracle Net Client 10.2.0.1.0
■an Oracle Adapter, version 10.2.0.1.0
Oracle Net software is included in this Oracle Transparent Gateway for DRDA release.
Your gateway license includes a license for Oracle Net and an adapter of your choice.
This license restricts the use of Oracle Net for gateway access.
3.3 Documentation Requirements
In addition to the documentation provided with the Oracle Transparent Gateway for
DRDA distribution kit, the following Oracle documentation is recommended:
■Oracle Database Administrator's Guide
■Oracle Database Installation Guide for Microsoft Windows (32-Bit)
■Oracle Database PL/SQL User's Guide and Reference
■Oracle Database SQL Reference
System Requirements 3-3
Documentation Requirements
■Oracle Database Net Services Administrator's Guide
■Oracle Database Net Services Reference
In addition to the Oracle documentation, ensure that you have the required
documentation for the platform, for the operating system, and for theDRDA Server
(DB2/OS390, DB2/400, DB2 Universal Database, or DB2 server for VM).
IBM publications that describe distributed relational databases might also be useful.
3-4 Oracle Transparent Gateway for DRDA Installation and User's Guide
4
Installing the Gateway
This chapter provides general information about gateway installation that is specific to
this release of the Oracle Transparent Gateway for DRDA for Microsoft Windows. This
chapter includes the following sections:
■Introduction
■Before You Begin
■Checklist for Gateway Installation
■Installation Overview
■Preinstallation
■Installing the Gateway from the Installation Media
■Installation Complete
4.1 Introduction
The complete Oracle Transparent Gateway for DRDA for Microsoft Windows
installation process is divided into installation and configuration tasks. This process is
described in Chapters 4 through 8. If this is the first time the gateway has been
installed on your Pentium-based host, then you must perform all the steps
documented in these chapters.
The installation tasks include:
■Ensuring that your hardware and software requirements are met
■Loading and installing the gateway software from the distribution medium into
your system
■Determining your gateway system identifier
■Reconfiguring your network
An installation checklist follows, which you can use to check off each completed step
in the process.
4.2 Before You Begin
This chapter requires you to enter parameters that are unique to your system in order
to properly configure the gateway. Refer to Appendix E, "Configuration Worksheet"
for a worksheet listing all the installation parameters that you will need to know in
Installing the Gateway 4-1
Checklist for Gateway Installation
order to complete the configuration process. Ask your network administrator to
provide these parameters before you begin.
You will also need to confirm that all hardware and software requirements have been
met. Refer to Chapter 3, "System Requirements" to verify these requirements.
4.3 Checklist for Gateway Installation
Use the following checklist for installing the gateway:
■Step 1: Log on to the host
■Step 2: Load the CD-ROM into the CD-ROM Drive
■Step 3: Start the Oracle Universal Installer on Microsoft Windows
■Step 4: Step through the Oracle Universal Installer
■Step 5: Verify Installation Success
4.4 Installation Overview
The primary installation tasks are presented with the assumption that you will
configure the gateway with a single Oracle integrating server and a single DRDA
database. The steps for expanding the configuration to multiple integrating servers
and multiple DRDA databases are described in Chapter 10, "Configuring the
Gateway".
For general information about installing Oracle products and how to use the Oracle
Universal Installer, refer to the Oracle Database Installation Guide for Microsoft Windows (32-Bit).
4.5 Preinstallation
ORACLE_HOME is the root directory in which Oracle software is installed.
Throughout this book, ORACLE_HOME is used to refer to the home directory of the
Oracle Transparent Gateway for DRDA for Microsoft Windows, unless specifically
stated otherwise.
4.6 Installing the Gateway from the Installation Media
The Oracle Universal Installer for Microsoft Windows is provided on the installation
media with the gateway.
4.6.1 Step 1: Log on to the host
Log on to your host computer as a member of the Administrators group.
4.6.2 Step 2: Load the CD-ROM into the CD-ROM Drive
Use any CD-ROM drive that is attached to the Pentium-based host (either locally or as
a shared resource) as a logical drive to install the gateway. If the CD-ROM drive cannot
copy files to your hard disk, then refer to your CD-ROM documentation. The
installation steps are presented with the assumption that the CD-ROM drive is
mapped to the G: drive.
To load the gateway distribution CD-ROM:
4-2 Oracle Transparent Gateway for DRDA Installation and User's Guide
Insert the gateway distribution CD-ROM into the CD-ROM drive.
1.
2. Verify that the drive is assigned to the logical drive that you selected and that you
can access files on the CD-ROM.
4.6.3 Step 3: Start the Oracle Universal Installer on Microsoft Windows
If you previously installed another Oracle Microsoft Windows product, such as an
earlier version of the Oracle server or the gateway, then Oracle Universal Installer has
already been set up in the Microsoft Windows program menu.
Start the Oracle Universal Installer from the Start menu rather than by using
Microsoft Windows Explorer.
1. From the Start menu, click Run.
2. Enter the path and executable file name:
G:\SETUP.EXE
3. Click OK.
4.6.4 Step 4: Step through the Oracle Universal Installer
The Oracle Universal Installer is a menu-driven utility that guides you through
installation of the gateway by prompting you with action items. The action items and
the sequence in which they appear depend on your platform. Use the following table
as a guide to the installation, following the instructions in the Response column.
Installation Complete
Table 4–1Steps to Install the Gateway Using the Oracle Universal Installer
PromptResponse
We lc om eC li ck Next.
Specify Home DetailsCheck that the destination path points to your ORACLE_HOME.
Click Next.
Available Product
Components
DRDA Network Interface
Product Software
SummaryVerify the products to be installed. Click Next.
Open the Oracle Transparent Gateways product group and
select Oracle Transparent Gateway for DRDA. Open the Oracle
Transparent Gateway for DRDA product group, if not already
open, and select one protocol from the list of supported
protocols. Remove selection from everything else for a
standalone gateway installation. Click Next.
If the SNA protocol was selected, choose the network interface
software suitable for this installation of the gateway. Click Next.
If the SNA protocol was not selected, this panel does not
appear.
4.6.5 Step 5: Verify Installation Success
After the Oracle Universal Installer confirms that the installation has ended, verify that
the installation was successful. To do this, check the contents of the installation log file,
which is located in the C:\Program Files\Oracle\Inventory\logs directory. The
default file name is InstallActionsdate.LOG.
4.7 Installation Complete
Your gateway installation is now complete. Proceed with the configuration tasks that
are described in Chapters 5 through 10.
Installing the Gateway 4-3
Installation Complete
4.7.1 Removing the Gateway
Removing the Oracle Transparent Gateway for DRDA requires the use of the Oracle
Universal Installer. Follow the procedures below to remove the gateway:
1. To restart the Oracle Universal Installer, refer to the installation process found
earlier in this chapter in "Installing the Gateway from the Installation Media" on
page 4-2, and repeat the following three steps (Steps 1, 2, and 3):
a. Step 1: Log on to the host
b. Step 2: Load the CD-ROM into the CD-ROM Drive
c. Step 3: Start the Oracle Universal Installer on Microsoft Windows
2. When the Welcome panel appears, select Advanced Installation and Click Next.
Then, in the File Locations panel, click Installed Products.
3. In the list of installed products, select the Gateway product and any other
products that you wish to remove, and click Remove.
4-4 Oracle Transparent Gateway for DRDA Installation and User's Guide
5
Configuring the DRDA Server
The steps for configuring your remote DRDA Server apply to the following DRDA
Servers:
■Checklists for Configuring the DRDA Server
■DB2/OS390
■DB2/400
■DB2/UDB (Universal Database)
■DB2/VM
Configuring a DRDA database to enable access by the gateway requires actions on the
DRDA database and on certain components of the host operating system. Although no
Oracle software is installed on the host system, access to, and some knowledge of, the
host system and DRDA database are required during the configuration. Refer to the
vendor documentation for complete information about your host system and DRDA
database.
5.1 Checklists for Configuring the DRDA Server
Use the following checklists for configuring the DRDA Server.
5.1.1 DB2/OS390
■Step 1: Configure the Communications Server
■Step 2: Define the user ID that owns the package
■Step 3: Define the recovery user ID
■Step 4: Determine DRDA location name for DB2 instance
■Step 5: Configure DB2 Distributed Data Facility for Gateway
5.1.2 DB2/400
■Step 1: Configure the Communications Server
■Step 2: Define the user ID that owns the package
■Step 3: Define the recovery user ID
■Step 4: Determine DRDA location name for DB2/400 instance
Configuring the DRDA Server 5-1
DB2/OS390
5.1.3 DB2/UDB (Universal Database)
■Step 1: Configure the SNA Communications Server
■Step 2: Define the user ID that owns the package
■Step 3: Define the recovery user ID
■Step 4: Determine DRDA location name for DB2/UDB instance
5.1.4 DB2/VM
■Step 1: Configure the Communications Server
■Step 2: Define the user ID that owns the package
■Step 3: Define the recovery user ID
■Step 4: Determine DRDA location name for DB2/VM instance
5.2 DB2/OS390
Experience with OS/390 (MVS), OS/390, TSO, VTAM, and DB2 is required to perform
the following steps:
5.2.1 Step 1: Configure the Communications Server
If you are using SNA, then configure OS/390 (MVS) VTAM for the SNA connection
from the host. Configure DB2 Distributed Data Facility (DDF) for SNA using the
Logical Unit (LU) defined. If you are using TCP/IP, then configure the TCP/IP
subsystem. Configure DB2's DDF subsystem to use TCP/IP, and assign a primary and
recovery port number for the DB2 server.
5.2.2 Step 2: Define the user ID that owns the package
During gateway configuration, you will need to run the Bind Package Stored
Procedure to bind the gateway package on the DRDA Server. To properly bind the
package, the user ID and password that are used when the procedure is run (either
implied as the current Oracle user or explicitly defined in the CREATE DATABASE LINK command) must have proper authority on the DRDA Server to create the
package. This same user ID should be used to create and to own the ORACLE2PC
(two-phase commit) table. The user ID that is used to bind or rebind the DRDA
package must have one or more of the following privileges on the DRDA Server:
■Package privileges of BIND, COPY, and EXECUTE, for example:
GRANT BIND ON PACKAGE drda1.* TO userid
GRANT COPY ON PACKAGE drda1.* TO userid
GRANT EXECUTE ON PACKAGE drda1.* TO PUBLIC
■Collection privilege of CREATE IN, for example:
GRANT CREATE IN ON PACKAGE drda1 TO USER userid
■System privileges of BINDADD and BINDAGENT, for example:
GRANT BINDADD TO USER userid
GRANT BINDAGENT TO USER userid
■Database privilege of CREATETAB, for example:
5-2 Oracle Transparent Gateway for DRDA Installation and User's Guide
GRANT CREATETAB ON DATABASE database TO USER userid
Choose a user ID now that will own the package and the ORACLE2PC table. Ensure
that this user ID is defined to both DB2 and OS/390 (MVS).
5.2.3 Step 3: Define the recovery user ID
During gateway configuration, the recovery user ID and password are specified in the
gateway initialization file using the DRDA_RECOVERY_USERID and
DRDA_RECOVERY_PASSWORD parameters. If a distributed transaction fails, then the
recovery process connects to the remote database using the user ID and password that
are defined in these parameters. This user ID must have execute privileges on the
package and must be defined to the DRDA database. If the user ID is not specified in
DRDA_RECOVER_USERID, then the gateway attempts to connect to a user ID of
ORARECOV when a distributed transaction is in doubt.
Determine the user ID and password that you will use for recovery.
5.2.4 Step 4: Determine DRDA location name for DB2 instance
The DRDA location name is required as a gateway parameter. To determine the
location name, run the SQL query from a DB2 SPUFI session:
DB2/400
SELECT CURRENT SERVER FROM any_table
where any_table is a valid table with one or more rows.
If the value returned by this query is blank or null, then the DRDA location name has
not been established. Contact the system administrator to arrange to set a location
name for the instance.
5.2.5 Step 5: Configure DB2 Distributed Data Facility for Gateway
DB2 DDF is the component of DB2 that manages all distributed database operations,
both DRDA and non-DRDA.
If your site uses DB2 distributed operations, then DDF is probably operational on the
DB2 instance that you plan to access through the gateway. If DDF is not operational,
then you must configure it and start it as described in the appropriate DB2
documentation.
Even if DDF is operational on the DB2 instance, it might be necessary to make changes
to the DDF Communication Database (CDB) tables to specify the authorization
conduct of DRDA sessions from the gateway. This can be done by properly authorized
users with a utility such as the DB2 SPUFI utility. If you make changes to CDB tables,
then you must stop and restart DDF for the changes to take effect. Refer to Chapter 13,
"Security Considerations", for additional CDB tables and security information.
5.3 DB2/400
Experience with DB2/400 and AS/400 is required to perform the following steps:
5.3.1 Step 1: Configure the Communications Server
If you are using SNA, then configure AS/400 communications for the SNA connection
from the host. Configure DB2/400 for SNA using the LU defined. If you are using
TCP/IP, then configure the TCP/IP subsystem, configure DB2/400 to use TCP/IP,
and assign a Primary and Recovery port number for the DB2 server.
Configuring the DRDA Server 5-3
DB2/UDB (Universal Database)
5.3.2 Step 2: Define the user ID that owns the package
During gateway configuration, you will need to run the Bind Package Stored
Procedure to bind the gateway package on the DRDA Server. To properly bind the
package, the user ID and password that are used when the procedure is run (either
implied as the current Oracle user or explicitly defined in the CREATE DATABASE LINK command) must have proper authority on the DRDA Server to create the
package. This same user ID should be used to create and to own the ORACLE2PC
(two-phase commit) table. The user ID that is used to bind or rebind the DRDA
package must have the following privileges on the DRDA Server:
■Use authority on the CRTSQLPKG command
■Change authority on the library in which the package will be created
Choose a user ID now that will own the package and the ORACLE2PC table. Ensure
that this user ID is defined to DB2/400 and AS/400.
5.3.3 Step 3: Define the recovery user ID
During gateway configuration, the recovery user ID and password are specified in the
gateway initialization file using the DRDA_RECOVERY_USERID and DRDA_RECOVERY_PASSWORD parameters. If a distributed transaction fails, then the
recovery process connects to the remote database using the user ID and password that
are defined in these parameters. This user ID must have execute privileges on the
package and must be defined to the DRDA database. If the user ID is not specified in
DRDA_RECOVER_USERID, then the gateway attempts to connect to a user ID of
ORARECOV when a distributed transaction is in doubt.
Determine the user ID and password that you will use for recovery.
5.3.4 Step 4: Determine DRDA location name for DB2/400 instance
The DRDA location name is required as a gateway parameter. To determine the
location name, run the following SQL query from a STRSQL session. If SQL is
unavailable on the system, then use the AS/400 command DSPRDBDIRE to identify
your "LOCAL" DRDA Server.
SELECT CURRENT SERVER FROM any_table
where any_table is a valid table with one or more rows.
If the value returned by this query is blank or null, then the DRDA location name has
not been established. Contact the system administrator to arrange to set a location
name for the instance.
5.4 DB2/UDB (Universal Database)
Experience with DB2/UDB, configuring the communication subsystem of DB2/UDB,
and the host System Administration tools is required to perform the following steps.
5.4.1 Step 1: Configure the SNA Communications Server
If you are using SNA, then configure the communications server for the connection
from the host. Configure DB2/UBD for SNA using the LU defined. If you are using
TCP/IP, then configure the TCP/IP subsystem. Configure DB2/UDB to use TCP/IP,
and assign a primary and recovery port number for the DB2 server.
5-4 Oracle Transparent Gateway for DRDA Installation and User's Guide
5.4.2 Step 2: Define the user ID that owns the package
During gateway configuration, you will need to run the Bind Package Stored
Procedure to bind the gateway package on the DRDA Server. To properly bind the
package, the user ID and password that are used when the procedure is run (either
implied as the current Oracle user or explicitly defined in the CREATE DATABASE LINK command) must have proper authority on the DRDA Server to create the
package. This same user ID should be used to create and to own the ORACLE2PC
(two-phase commit) table. The user ID that is used to bind or rebind the DRDA
package must have one or more of the following privileges on the DRDA Server:
■Package privileges of BIND and EXECUTE, for example:
GRANT BIND ON PACKAGE drda1.g2drsql TO USER userid
GRANT EXECUTE ON PACKAGE drda1.g2drsql TO PUBLIC
■Schema privileges of CREATEIN, for example:
GRANT CREATEIN ON SCHEMA otgdb2 TO USER userid
GRANT CREATEIN ON SCHEMA drda1 TO USER userid
■Database authorities of CONNECT, BINDADD, and CREATETAB, for example:
GRANT CONNECT ON DATABASE TO USER userid
GRANT BINDADD ON DATABASE TO USER userid
GRANT CREATETAB ON DATABASE TO USER userid
DB2/VM
Now choose a user ID that will own the package and ORACLE2PC table. Ensure that
this user ID is defined to both the DB2 instance ID and the operating system.
5.4.3 Step 3: Define the recovery user ID
During gateway configuration, the recovery user ID and password are specified in the
gateway initialization file using the DRDA_RECOVERY_USERID and
DRDA_RECOVERY_PASSWORD parameters. If a distributed transaction fails, then the
recovery process connects to the remote database using the user ID and password that
are defined in these parameters. This user ID must have execute privileges on the
package and must be defined to the DRDA database. If the user ID is not specified in
DRDA_RECOVER_USERID, then the gateway attempts to connect to a user ID of
ORARECOV when a distributed transaction is in doubt.
Determine the user ID and password that you will use for recovery.
5.4.4 Step 4: Determine DRDA location name for DB2/UDB instance
The DRDA location name is required as a gateway parameter. To determine the
location name, run the SQL query from a DB2 CLI session:
SELECT CURRENT SERVER FROM any_table
where any_table is a valid table with one or more rows.
If the value returned by this query is blank or null, then the DRDA location name has
not been established. Contact your system administrator to arrange to set a location
name for the instance.
5.5 DB2/VM
Experience with VM, AVS, and DB2/VM is required to perform the following steps:
Configuring the DRDA Server 5-5
DB2/VM
5.5.1 Step 1: Configure the Communications Server
If you are using SNA, then configure VM VTAM and AVS for the SNA connection
from the host. If you are using TCP/IP, then configure the TCP/IP service.
5.5.2 Step 2: Define the user ID that owns the package
During gateway configuration, you will need to run the Bind Package Stored
Procedure to bind the gateway package on the DRDA Server. To properly bind the
package, the user ID and password that are used when the procedure is run (either
implied as the current Oracle user or explicitly defined in the CREATE DATABASE LINK command) must have proper authority on the DRDA Server to create the
package. This same user ID should be used to create and to own the ORACLE2PC
(two-phase commit) table. The user ID that is used to bind or rebind the DRDA
package must have the following privileges on the DRDA Server:
■Package privileges of BIND, COPY, and EXECUTE
■Collection privilege of CREATE IN
■System privileges of BINDADD and BINDAGENT
Choose a user ID now that will own the package and ORACLE2PC table. Ensure that
this user ID is defined to DB2/VM and VM.
5.5.3 Step 3: Define the recovery user ID
During gateway configuration, the recovery user ID and password are specified in the
gateway initialization file using the DRDA_RECOVERY_USERID and
DRDA_RECOVERY_PASSWORD parameters. If a distributed transaction fails, then the
recovery process connects to the remote database using the user ID and password that
are defined in these parameters. This user ID must have execute privileges on the
package and must be defined to the DRDA database. If the user ID is not specified in
DRDA_RECOVER_USERID, then the gateway attempts to connect to a user ID of
ORARECOV when a distributed transaction is in doubt.
Determine the user ID and password that you will use for recovery.
5.5.4 Step 4: Determine DRDA location name for DB2/VM instance
The DRDA location name is required as a gateway parameter. To determine the
location name, run the SQL query from an iSQL session:
SELECT CURRENT SERVER FROM any_table
where any_table is a valid table with one or more rows.
If the value returned by this query is blank or null, then the DRDA location name has
not been established. Contact the system administrator to arrange to set a location
name for the instance.
5-6 Oracle Transparent Gateway for DRDA Installation and User's Guide
6
Configuring Microsoft SNA Server or Host
Integration Server
This chapter describes configuration of the Microsoft SNA Server product on
Microsoft Windows for use with the Oracle Transparent Gateway for DRDA. The SNA
Server provides the SNA connectivity through the APPC/LU6.2 protocol between the
Pentium-based host and the remote DRDA Server. Microsoft Host Integration Server is
the successor product to Microsoft SNA Server, but it retains the same configuration
information as SNA Server and the steps for configuring SNA Server, therefore, also
apply to Host Integration Server. Read this chapter to learn more about creating server
profiles.
This chapter contains the following sections:
■Before You Begin
■Steps for Configuring the Communications Interfaces
■Creating SNA Server Profiles for the Gateway
■Creating SNA Definitions for the Gateway
■Testing the Connection
■Using SNA Session Security Validation
■SNA Conversation Security
6.1 Before You Begin
This chapter requires you to enter parameters unique to your system in order to
properly configure the SNA Server. Refer to Appendix E for a worksheet listing all the
installation parameters that you will need to know before you can complete the
configuration process. Ask your network administrator to provide you with these
parameters before you begin.
6.2 Steps for Configuring the Communications Interfaces
■Step 1: Creating SNA Server Profiles for the Gateway
■Step 2: Creating SNA Definitions for the Gateway
■Step 3: Testing the Connection
Configuring Microsoft SNA Server or Host Integration Server 6-1
Creating SNA Server Profiles for the Gateway
6.3 Creating SNA Server Profiles for the Gateway
The Oracle Transparent Gateway for DRDA requires a stored set of definitions, called
Side Information Profiles, to support connections between the gateway and DRDA
Servers. Each profile consists of a profile name and a profile type, a set of fields
describing the profile. The fields in a given profile type are generally a mixture of
operating parameter values and names of other SNA profiles relevant to the profile.
Each functional part of APPC, such as the Mode, Remote Transaction Program name,
and Logical Unit (LU), is described by a distinct profile type.
6.3.1 Independent Versus Dependent LUs
Oracle recommends independent LUs for the Oracle Transparent Gateway for DRDA,
because they support multiple parallel sessions or conversations. This means the
multiple Oracle client applications can be active simultaneously with the same DRDA
Server through the independent LU.
Dependent LUs support only a single active session. The CP (SNA Server for Microsoft
Windows, in this case) queues additional conversation requests from the gateway
server behind an already active conversation. In other words, conversations are
single-threaded for dependent LUs.
If a dependent LU is correctly defined, then no alterations to the Oracle Transparent
Gateway for DRDA configuration are needed, nor should any changes be needed to
the DRDA Server.
The operational impact of dependent LUs is that the first client application can start a
conversation through the gateway with the DRDA Server. While that session is active
(which could be seconds, minutes, or hours, depending on how the client application
and transaction are designed), any other client application starting a session with the
same DRDA Server appears to stop responding as it waits behind the previous session.
If a production application really uses only one conversation at any one time, then
there should be no impact. However, additional concurrent conversations might be
required for testing or other application development. Each requires that additional
dependent LUs be defined on the remote host, plus additional SNA Server
configuration entries which define the additional dependent LUs on the host.
Additional Side Information Profiles should be defined to use the new dependent LUs.
New Oracle Transparent Gateway for DRDA instances should be created and
configured to use these new Side Information Profiles.
6.4 Creating SNA Definitions for the Gateway
SNA Server definitions can be created and modified in two ways:
■Directly with the SNACFG command
■Using menus in SNA Server Manager
Maintenance of SNA definitions is normally done by a user with Administrator
authority. This information is intended for the person creating SNA definitions for the
gateway. You should have some knowledge of SNA before reading this section.
6.4.1 Sample SNA Server Definitions
The tg4drda\sna\mssna subdirectory contains a sample set of gateway SNA Server
definitions created with the SNACFG command. The snacfg.ctl file contains sample
definitions for SNA Server.
6-2 Oracle Transparent Gateway for DRDA Installation and User's Guide
Before building the SNA Server definitions, examine the snacfg.ctl file to determine the
definitions needed, their contents, and their interrelationships. The file format is
text-oriented and each field of each definition is clearly labeled. You can print a copy
of the file to use while working with your definitions in an SNA Server Admin or SNA
Server Manager session.
You can create and modify these definitions in two ways:
■Install the definitions directly on the system using the SNACFG command.
For information on using the SNACFG command, refer to the SNA Server
Administration Guide in the Microsoft SNA Server online documentation.
If you use this method, then you must use SNA Server Manager to review and
modify the installed definitions. Because of configuration and naming differences,
it is unlikely that they will work without modification.
■Create the definitions.
SNA Server Manager is the recommended method for creating the definitions. You
should be able to accept most of the defaults. The default values assigned to many
of the fields in a new set of definitions are acceptable for the gateway.
6.4.2 Definition Types
There are several types of SNA Server definitions relevant to gateway APPC/LU6.2
operation. Each definition can be created and edited using a corresponding SNA
Server Manager menu.
Creating SNA Definitions for the Gateway
The definitions relevant to the gateway are presented here in hierarchical order. Those
definition types that are lowest in the hierarchy are discussed first. This matches the
logical sequence in which to create the profiles.
Refer to the Microsoft SNA Server online documentation for a complete discussion of
SNA Server definitions. This section is an overview of SNA Server definitions in
relation to the Oracle Transparent Gateway for DRDA for Microsoft Windows.
Note: Before beginning to create and edit profiles using SNA
Server Admin, you must install the DLC protocol and create the
link service. Prior to running SNA Server Admin, use the
Microsoft Windows Control Panels Network Manager to install the
DLC protocol.
6.4.3 SNA Server Definitions
This section describes the process of creating your SNA definitions for SNA Server
version 3, using SNA Server Manager. All the tasks described in this section are
performed from within SNA Server Manager. The other primary administration tool is
the SNA Server Management Console. Both tools provide access to the same SNA
definitions for the Node, but in slightly different views. The SNA Server Manager
gives a localized view of the Node, while the SNA Server Management Console
presents a more global view, where the local node may be one of many SNA Nodes in
a network that is managed by this syatem. Later versions of SNA Server and Host
Integration Server tools may reorganize the profiles placement within the definition
tree, but the concepts remain the same. Some extrapolation by the user may be
necessary.
Configuring Microsoft SNA Server or Host Integration Server 6-3
Creating SNA Definitions for the Gateway
Figure 6–1 SNA Server Manager Main Screen: Select a Server
6.4.3.1 Server Selection
The correct SNA Server must be selected to ensure that definitions created are for that
server. Start the SNA Server Manager.
Click the SNA subdomain under your local system (in this example, ITDEV11) and
then click to open the SNA Servers folder. From a list of services for that server, select
the SNA Service of your choice (in this illustration, ITDEV-NT11). Click to open it.
Figure 6–2 Server Properties Dialog Box
6-4 Oracle Transparent Gateway for DRDA Installation and User's Guide
Creating SNA Definitions for the Gateway
6.4.3.2 Service Properties
Each SNA Server must have a primary service definition. From the Service menu in
the SNA Server Manager window, select Properties. In the Server Properties dialog
box, under the General tab, change the Network Name and Control Point Name as
needed. Click OK.
Figure 6–3 Insert Link Service
6.4.3.3 Link Service Definition
A link service must be installed and configured in order for SNA Server to use the
network adapter installed in your workstation. From the Insert menu, select Link
Service. In the Insert Link Service dialog box, select the desired Link Service from the
selection list and click Add. In this example, DLC 802.2 Link Service is selected.
Configuring Microsoft SNA Server or Host Integration Server 6-5
Creating SNA Definitions for the Gateway
Figure 6–4 Select Link Service Properties
Now, the Link Service Properties dialog box is displayed. Note that the contents of this
dialog box will vary, depending on which Link Service was selected. In this example,
the DLC 802.2 Link Service Properties box dialog is used:
Select the suitable network adapter from the Adapter drop-down list and click OK. In
the Insert Link Service dialog box, click OK. The system now updates the network
bindings.
Figure 6–5 Connection Properties Menu
6-6 Oracle Transparent Gateway for DRDA Installation and User's Guide
Creating SNA Definitions for the Gateway
6.4.3.4 Connection Definition
You must create a connection definition to define the devices which SNA Server uses
to perform SNA communication. From the Insert menu, select Connection and choose
the connection type (802.2 is used in this example). The Connection Properties dialog
box appears.
Figure 6–6 General Connection Properties
Select the General tab. Enter a Connection Name. This is the name used by SNA Server
to name the connection. This example names the connection HQMVS2. From the Link
Service drop-down list, select a link service for the connection. All other settings can
be left set to their default values.
Figure 6–7 Enter Remote Addresses
Select the Address tab. Enter values for Remote Network Address and the Remote
SAP address.
Configuring Microsoft SNA Server or Host Integration Server 6-7
Creating SNA Definitions for the Gateway
Figure 6–8 Enter System Identification
Now, select the System Identification tab. Under Local Node Name, enter the Network
Name, Control Point Name, and Local Node ID. Under Remote Node Name, enter the
Network Name, Control Point Name, and optionally, the Remote Node ID. The XID
Type should be set to Format 3.
Figure 6–9 Enter DLC Values
Next, select the DLC tab. In this example, the 802.2 DLC (Token Ring) is being used.
For the 802.2 DLC, all of the defaults are usually acceptable. If you need to change any
values, then do so now. Now, all the connection properties are set. Click OK.
6-8 Oracle Transparent Gateway for DRDA Installation and User's Guide
Figure 6–10 Local LU Properties Menu
Creating SNA Definitions for the Gateway
6.4.3.5 Local LU Definition
You must create a local LU definition. The local LU definition describes the SNA LU
through which the gateway communicates with DRDA Server systems.
From the Insert menu, select APPC Local LU. The Local APPC LU Properties dialog
box appears.
Figure 6–11 Enter Local APPC LU Properties
Configuring Microsoft SNA Server or Host Integration Server 6-9
Creating SNA Definitions for the Gateway
Select the General tab. Enter LU Alias, Network Name, and LU Name. You should
contact the person responsible for your SNA network to determine the correct LU and
network names.
Figure 6–12 Set Up Parallel Session
Select the Advanced tab. Check the Member of Default Outgoing Local APPC LU Pool
box. Set the LU 6.2 Type to Independent to enable parallel sessions. Ensure that the
APPC Syncpoint Support box is not checked.
Now, the Local LU properties are all set. Click OK button to continue.
Figure 6–13 Select APPC Mode Definition
6-10 Oracle Transparent Gateway for DRDA Installation and User's Guide
Creating SNA Definitions for the Gateway
6.4.3.6 Mode Definition
This definition describes an SNA mode entry to be used when establishing sessions
between LUs. The mode defined here must match a mode defined on the target
system.
From the Insert menu, select APPC Mode Definition. The APPC Mode Properties
dialog box appears.
Figure 6–14 APPC Mode General Properties Dialog Box
Select the General tab. Enter the Mode Name. The mode name that you specify must
be defined to the DRDA Server communications software. Choose the mode name and
other mode parameters after consulting the person responsible for configuring the
DRDA Server communications software.
Figure 6–15 Enter the APPC Mode Limits
Next, select the Limits tab. Enter values for Parallel Session Limit, Minimum
Contention Winner Limit, Partner Min Contention Winner Limit, and Automatic
Activation Limit. The Parallel Session limit determines the maximum number of
Configuring Microsoft SNA Server or Host Integration Server 6-11
Creating SNA Definitions for the Gateway
concurrent conversations permitted between the gateway instance and the DRDA
Server. This equates to the maximum number of concurrently active remote sessions
through the gateway instance.
Figure 6–16 Set APPC Mode Characteristics
Now, select the Characteristics tab. Enter the Pacing Send Count, Pacing Receive
Count, Max Send RU Size, and Max Receive RU size. For optimal performance, check
the High Priority Mode box. The pacing and RU size parameters are
performance-related and should be tuned to suit your application. For most
installations, the values set in the example will be sufficient.
Now, all the APPC mode properties are set. Click OK to continue.
Figure 6–17 APPC Remote LU Menu
6-12 Oracle Transparent Gateway for DRDA Installation and User's Guide
Creating SNA Definitions for the Gateway
6.4.3.7 Remote LU Definition
This definition describes the SNA LU of the DRDA Server system with which the
gateway communicates. You must create a remote LU definition for the remote DRDA
Server system. From the Insert menu, select APPC Remote LU. The Remote APPC LU
Properties dialog box appears.
Figure 6–18 Enter General Remote APPC LU Properties
Select the General tab. Determine the link with which to associate the LU (in the
example, HQMVS2). Use the Connection drop-down list to select the connection used to
access this LU. Enter the LU Alias, Network Name, LU Name, and Uninterpreted LU
Name. You should contact the person responsible for your SNA network to determine
the correct LU and network names. Note that you can use the LU Alias to define a
name known only to SNA Server, and that name can remain the same even if the
remote LU name changes. This helps to reduce the amount of maintenance required
when network changes occur.
Figure 6–19 Remote APPC LU Properties Options
Configuring Microsoft SNA Server or Host Integration Server 6-13
Creating SNA Definitions for the Gateway
Now, select the Options tab. Check the Supports Parallel Sessions check box. Use the
Implicit Incoming Mode drop-down listto select the mode. Set any security options
you need.
The remote APPC LU properties are now set. Click OK to continue.
Figure 6–20 CPI-C Symbolic Destination Name Window
6.4.3.8 CPI-C Symbolic Destination Names
Once the Local and Remote Partner definitions and Mode definitions have been
created, you can create CPI-C Symbolic Destination Names, also called Side
Information Profiles. The Side Information Profiles are used to identify target DRDA
Server systems to be accessed through the gateway. From the Insert menu, select APPC
CPI-C Symbolic Name. The CPI-C Name Properties dialog box appears.
6-14 Oracle Transparent Gateway for DRDA Installation and User's Guide
Testing the Connection
Figure 6–21 Enter General CPI-C Name Properties
Select the General tab. Enter a Name for Side Information. From the Mode Name
drop-down list, select the correct mode.
Note: The DRDA_CONNECT_PARM should be assigned the name of
the CPI-C Side Information Name entered earlier.
Figure 6–22 Enter CPI-C Name Properties Partner Information
Now, select the Partner Information tab. Select Application TP and enter the TP name.
Enter the Partner LU Name alias. Click OK to save the Side Information.
6.5 Testing the Connection
Before proceeding with the gateway configuration tasks in Chapter 10, "Configuring
the Gateway", ensure that your connection is working. This can be done using SNA
Server Manager.
Configuring Microsoft SNA Server or Host Integration Server 6-15
Using SNA Session Security Validation
Figure 6–23, "Relationship Between SNA Server Definitions and Host VTAM
Definitions" shows the relationship between SNA Server definitions and the VTAM
definitions on the host.
Figure 6–23 Relationship Between SNA Server Definitions and Host VTAM Definitions
Local LU Defination
Local LU Alias
Local LU Name
...
Connection Definition
Connection Name
...
Side Information
Local LU Alias
Partner LU Alias
or
Fully-qualified
Partner LU Name
Mode Name
Remote TP Name
Partner LU Definition
Fully-qualified
Partner LU Name
netname.pluname
Partner LU Alias
Connection
...
Mode Definition
Mode Name
...
VTAMLST
APPL Definition
pluname APPL...
MODETAB=mtname
ATCSTR00
NETWORK=netname
SSCPNAME=cpname
VTAM Mode Table
mtname MODETAB
MODEENT
LOGMODE=mode
name
6.6 Using SNA Session Security Validation
When the database link request for the gateway begins, the gateway attempts to start
an APPC conversation with the DRDA Server. Before the conversation can begin, a
session must start between the host Logical Unit (LU) and the DRDA Server LU.
SNA and its various access method implementations (including Microsoft SNA
Server) provide security validation at session initiation time, enabling each LU to
authenticate its partner. This is carried out entirely by network software before the
gateway and server application programs begin their conversation and process
conversation-level security data. If session-level security is used, then correct
password information must be established in the Pentium-based host Connection
Profile and in similar parameter structures in the DRDA Server system that is to be
accessed. Refer to Microsoft SNA Server and IBM Communication Server product
documentation for detailed information.
6.7 SNA Conversation Security
SNA conversation security is determined by the setting of the gateway initialization
parameter, DRDA_SECURITY_TYPE. This parameter determines whether SNA security
option SECURITY is set to PROGRAM or to SAME. Generally, the gateway operates
under SNA option SECURITY=PROGRAM, but it can also be set to operate under SNA
option SECURITY=SAME.
6-16 Oracle Transparent Gateway for DRDA Installation and User's Guide
6.7.1 SNA Security Option SECURITY=PROGRAM
If DRDA_SECURITY_TYPE=PROGRAM is specified, then the gateway allocates the
conversation with SNA option SECURITY=PROGRAM and sends this information to the
DRDA Server:
■If the database link has explicit CONNECT information, then the specified user ID
and password are sent.
■If the database link has no CONNECT clause and if the application has logged in to
the Oracle integrating server with an explicit user ID and password, then the
Oracle user ID and password are sent.
■If the application logs in to the Oracle integrating server with operating system
authentication, and if the database link lacks explicit CONNECT information, then
no user ID and password are sent. If no user ID and password are sent, and if the
DRDA Server is not configured to assign a default user ID, then the connection
fails.
In general, SECURITY=PROGRAM tells the DRDA Server to authenticate the
user ID/password combination using whatever authentication mechanisms are
available. For example, if DB2/OS390 is the DRDA Server, then RACF can be used.
This is not always the case, however, because each of the IBM DRDA Servers can be
configured to process inbound user IDs in other ways.
SNA Conversation Security
6.7.2 SNA Security Option SECURITY=SAME
The SECURITY=SAME option is not directly supported by Microsoft SNA Server.
SECURITY=SAME implicitly validates security using the user account under which the
TNS Listener was started. Microsoft SNA Server, however, does not support this type
of validation.
Configuring Microsoft SNA Server or Host Integration Server 6-17
SNA Conversation Security
6-18 Oracle Transparent Gateway for DRDA Installation and User's Guide
7
Configuring IBM Communication Server
This chapter describes configuration of the IBM Communication Server product on
MS Windows for use with the Oracle Transparent Gateway for DRDA. IBM
Communication Server provides SNA connectivity through the APPC/LU6.2 protocol
between the host and the remote DRDA Server. Read this chapter to learn more about
creating Communication Server profiles.
This chapter contains the following sections:
■Before You Begin
■Checklist for Configuring the Communications Interfaces
■Creating IBM Communication Server Profiles for the Gateway
■Definition Types
■Testing the Connection
■Using SNA Session Security Validation
■SNA Conversation Security
7.1 Before You Begin
This chapter requires you to enterparameters unique to your system in order to
properly configure the IBM Communication Server. Refer to Appendix E for a
worksheet listing all the installation parameters that you will need to know before you
can complete the configuration process. Ask your network administrator to provide
you with these parameters before you begin.
7.2 Checklist for Configuring the Communications Interfaces
■Step 1: Creating IBM Communication Server Profiles for the Gateway
■Step 2: Definition Types
■Step 3: Testing the Connection
7.3 Creating IBM Communication Server Profiles for the Gateway
The Oracle Transparent Gateway for DRDA requires a stored set of definitions, called
Side Information Profiles, to support connections between the gateway and DRDA
Servers. Each profile consists of a profile name and a profile type, a set of fields
describing the profile. The fields in a given profile type are generally a mixture of
Configuring IBM Communication Server 7-1
Creating IBM Communication Server Profiles for the Gateway
operating parameter values and names of other SNA profiles relevant to the profile.
Each functional part of APPC, such as the Mode, Remote Transaction Program (RTP)
name, and Logical Unit (LU), is described by a distinct profile type.
7.3.1 Independent Versus Dependent LUs
Oracle recommends independent LUs for the Oracle Transparent Gateway for DRDA,
because they support multiple parallel sessions or conversations. This means multiple
Oracle client applications can be active simultaneously with the same DRDA Server
through the independent LU.
Dependent LUs support only one active session. The CP (IBM Communication Server,
in this case) queues additional conversation requests from the gateway server behind
an already active conversation. In other words, conversations are single-threaded for
dependent LUs.
If a dependent LU is correctly defined, then no alterations to the Oracle Transparent
Gateway for DRDA configuration are needed, nor should any changes be needed to
the DRDA Server.
The operational impact of dependent LUs is that the first client application can start a
conversation through the gateway with the DRDA Server. While that session is active
(which could be seconds, minutes, or hours, depending on how the client application
and transaction are designed), any other client application starting a session with the
same DRDA Server appears to stop responding as it waits behind the previous session.
If a production application really uses only one conversation at any one time, then
there should be no impact. However, additional concurrent conversations might be
required for testing or other application development. Each requires that additional
dependent LUs be defined on the remote host, plus additional IBM Communication
Server configuration entries which define the additional dependent LUs on the host.
Additional Side Information Profiles should be defined to use the new dependent LUs.
New Transparent Gateway for DRDA instances should be created and configured to
use these new Side Information Profiles.
7.3.2 Creating SNA Definitions for the Gateway
IBM Communication Server definitions are created using the SNA Node
Configuration tool, while the actual operation of the server is done using the SNA
Node Operations tool, both of which are provided with IBM Communication Server.
Maintenance of SNA definitions is normally done by a user with Administrator
authority.
7.3.2.1 Sample IBM Communication Server Definitions
The tg4drda\sna\commsvr subdirectory contains a sample set of IBM
Communication Server definitions created with the SNA Node Configuration tool.
The oracle.acg file contains sample definitions for IBM Communication Server.
Before building the IBM Communication Server definitions, examine the oracle.acg file
to determine the definitions needed, their contents, and their interrelationships. The
file format is text-oriented and each field of each definition is clearly labeled. You can
print a copy of the file to use while working with your definitions in an SNA Node
Configuration session.
7-2 Oracle Transparent Gateway for DRDA Installation and User's Guide
7.4 Definition Types
There are several types of IBM Communication Server definitions relevant to gateway
APPC/LU6.2 operation. Each definition can be created and edited using a
corresponding SNA Node Configuration menu.
The definitions relevant to the gateway are presented here in hierarchical order. Those
definition types that are lowest in the hierarchy are discussed first. This matches the
logical sequence in which to create the profiles.
Refer to the IBM Communication Server online documentation for a complete
discussion of IBM Communication Server definitions. This section is an overview of
IBM Communication Server definitions in relation to the Oracle Transparent Gateway
for DRDA.
7.4.1 IBM Communication Server Definitions
This section describes the process of creating SNA definitions for IBM Communication
Server using the SNA Node Configuration tool. All the tasks described in this section
are performed within SNA Node Configuration.
Figure 7–1 Choosing a Configuration Scenario
Definition Types
7.4.1.1 Creating the Configuration
SNA Node Configuration will first ask if you are creating a new configuration or
loading an existing configuration. The following example is presented with the
assumption that a new configuration is being created.
SNA Node Configuration will next prompt you for a configuration scenario. Our
example is made assuming that a CPI-C or APPC scenario is being chosen.
Configuring IBM Communication Server 7-3
Definition Types
Figure 7–2 Creating the Node Configuration
7.4.1.2 Defining the Node
Each SNA Server must have a Control Point defined. This is typically called the Node
definition. Click Node and click Create.
7-4 Oracle Transparent Gateway for DRDA Installation and User's Guide
Figure 7–3 Node Definition
Definition Types
In the Define the Node dialog box, in the Basic tab, enter the Control Point, Local Node
ID, and Node Type information. You can also select option in the Advanced tab
depending on your SNA network configuration. Click OK.
Configuring IBM Communication Server 7-5
Definition Types
Figure 7–4 Creating Devices
Communication devices should be configured next. Select Devices, and click Create.
Figure 7–5 Choosing the Device Type
Select the type of device to use for communication. The LAN type is typical for either
Ethernet or Token-ring attached network devices.
7-6 Oracle Transparent Gateway for DRDA Installation and User's Guide
Figure 7–6 Configuring a LAN Device
Definition Types
In the Basic tab, select the adapter to use and the local SAP. The other tabs may be
explored for network tuning parameters. Click OK.
Configuring IBM Communication Server 7-7
Definition Types
Figure 7–7 Creating Peer Connections
Peer connections should be configured next. Select Peer Connections, and click
Create.
7-8 Oracle Transparent Gateway for DRDA Installation and User's Guide
Figure 7–8 Defining the Link station
Definition Types
In the Basic tab, enter a link station name for this connection. Choose the Device for
the connection, and enter the destination address and remote SAP.
Configuring IBM Communication Server 7-9
Definition Types
Figure 7–9 Defining the Adjacent Node
Select the Adjacent Node tab. Enter the Adjacent CP name of the remote system and
pick its CP Type. You may have to choose a different Transmission Group (TG) as the
default. Consult your SNA Network Administrator for details. The other tabs may be
explored for tuning and link reactivation options. Click OK.
7-10 Oracle Transparent Gateway for DRDA Installation and User's Guide
Figure 7–10 Create Local LUs
Definition Types
Next, define the local LUs for this Node. Select Local LU 6.2 LUs, and click Create.
Figure 7–11 Defining Local LUs
Configuring IBM Communication Server 7-11
Definition Types
In the Basic tab, enter the name of the local LU and an alias, if desired. The name must
match the Local LU definition of the remote host for this node. The Advancedtab may
be explored for Synchronization support and for LU session limits. Click OK.
Figure 7–12 Create Partner LUs
Next, define remote Partner LUs for this Node to connect to. Select Partner LU 6.2 LUs
and click Create.
7-12 Oracle Transparent Gateway for DRDA Installation and User's Guide
Figure 7–13 Defining Partner LUs
Definition Types
In the Basic tab, enter the name of the remote or partner LU and an alias, if desired.
Seclect Fully Qualified CP from the existing list. The Advanced tab may be explored
for logical record limits and security support. Click OK.
Configuring IBM Communication Server 7-13
Definition Types
Figure 7–14 Creating the IBMRDB Mode
Next, define the IBMRDB mode, which will be used for DRDA connections. Select
Modes and click Create.
7-14 Oracle Transparent Gateway for DRDA Installation and User's Guide
Figure 7–15 Define the IBMRDB Mode
Definition Types
In the Basic tab, enter the name IBMRDB and the mode session limits. Consult your
SNA Network Administrator for details. The Advanced tab may be explored for
pacing and autoactivation session options. Click OK.
Configuring IBM Communication Server 7-15
Definition Types
Figure 7–16 Create the CPI-C Side Information Profile
Next, define the CPI-C profile that will be use dby the gateway. Select CPI-C side
information definitions and click Create.
7-16 Oracle Transparent Gateway for DRDA Installation and User's Guide
Figure 7–17 Define the CPI-C Side Information Profile
Testing the Connection
In the Basic tab, enter the Symbolic Destination name. Select IBMRDB for the Mode
name drop-down list, and select the Partner LU either by name or by alias. Enter the
TP name for the remote DRDA Server. Mode DRDA Servers use the default Service TP
name X'07F6C4C2' or '076DB'. Consult your DRDA Server Administrator for the
correct TP name. The Advancedtab may be explored for security options.
Note: The DRDA_CONNECT_PARM should be assigned the name of
the Symbolic Destination name as entered in Figure 7–16, "Create
the CPI-C Side Information Profile".
7.5 Testing the Connection
Before proceeding with the gateway configuration tasks in Chapter 10, "Configuring
the Gateway", ensure that your connection is working. This can be done by using the
SNA Node Operations tool.
Figure 7–18, "Relationship Between IBM Communication Server Definitions and Host
VTAM Definitions" shows the relationship between IBM Communication Server
definitions and the VTAM definitions on the host.
Configuring IBM Communication Server 7-17
Using SNA Session Security Validation
Figure 7–18 Relationship Between IBM Communication Server Definitions and Host VTAM Definitions
Local LU Defination
Local LU Alias
Local LU Name
...
Connection Definition
Connection Name
...
Side Information
Local LU Alias
Partner LU Alias
or
Fully-qualified
Partner LU Name
Mode Name
Remote TP Name
Partner LU Definition
Fully-qualified
Partner LU Name
netname.pluname
Partner LU Alias
Connection
...
Mode Definition
Mode Name
...
VTAMLST
APPL Definition
pluname APPL...
MODETAB=mtname
ATCSTR00
NETWORK=netname
SSCPNAME=cpname
VTAM Mode Table
mtname MODETAB
MODEENT
LOGMODE=mode
name
7.6 Using SNA Session Security Validation
When the database link request for the gateway begins, the gateway attempts to start
an APPC conversation with the DRDA Server. Before the conversation can begin, a
session must start between the host LU and the DRDA Server LU.
SNA and its various access method implementations (including IBM Communication
Server) provide security validation at session initiation time, enabling each LU to
authenticate its partner. This is carried out entirely by network software before the
gateway and server application programs begin their conversation and process
conversation-level security data. If session-level security is used, then correct
password information must be established in the Pentium-based host Connection
Profile and in similar parameter structures in the DRDA Server system that is to be
accessed. Refer to Microsoft SNA Server and IBM Communication Server product
documentation for detailed information.
7.7 SNA Conversation Security
SNA conversation security is determined by the setting of the gateway initialization
parameter, DRDA_SECURITY_TYPE. This parameter determines whether SNA
security option SECURITY is set to PROGRAM or to SAME. Generally, the gateway
operates under SNA option SECURITY=PROGRAM, but it can also be set to operate
under SNA option SECURITY=SAME.
7-18 Oracle Transparent Gateway for DRDA Installation and User's Guide
7.7.1 SNA Security Option SECURITY=PROGRAM
If DRDA_SECURITY_TYPE=PROGRAM is specified, then the gateway allocates the
conversation with SNA option SECURITY=PROGRAM and sends this information to the
DRDA Server:
■If the database link has explicit CONNECT information, then the specified user ID
and password are sent.
■If the database link has no CONNECT clause and if the application has logged in to
the Oracle integrating server with an explicit user ID and password, then the
Oracle user ID and password are sent.
■If the application logs in to the Oracle integrating server with operating system
authentication and if the database link lacks explicit CONNECT information, then
no user ID and password are sent. If no user ID and password are sent and if the
DRDA Server is not configured to assign a default user ID, then the connection
fails.
In general, SECURITY=PROGRAM tells the DRDA Server to authenticate the
user ID/password combination using whatever authentication mechanisms are
available. For example, if DB2/OS390 is the DRDA Server, then RACF can be used.
This is not always the case, however, because each of the IBM DRDA Servers can be
configured to process inbound user IDs in other ways.
SNA Conversation Security
7.7.2 SNA Security Option SECURITY=SAME
The SECURITY=SAME option is not directly supported by IBM Communication Server.
SECURITY=SAME implicitly validates security by using the user account under which
the TNS listener was started. IBM Communication Server, however, does not support
this type of validation.
Configuring IBM Communication Server 7-19
SNA Conversation Security
7-20 Oracle Transparent Gateway for DRDA Installation and User's Guide
This chapter describes configuring TCP/IP for the Microsoft Windows platforms that
are supported by the Oracle Transparent Gateway for DRDA. TCP/IP is a
communications facility that is already part of the operating system. No third-party
protocol software is required. Read this chapter to learn more about configuring
TCP/IP.
This chapter contains the following sections:
■Before You Begin
■Configuring TCP/IP
8.1 Before You Begin
This chapter requires you to enter parameters that are unique to your system in order
to properly configure TCP/IP. Refer to Appendix E for a worksheet listing all of the
installation parameters that you will need to know about before you complete the
configuration process. Ask your network administrator to provide you with these
parameters before you begin.
8
Configuring TCP/IP
8.1.1 Port Number
The DRDA standard specifies that port 446 be used for DRDA services. However, if
several DRDA Servers are operating on the same system, then they will need to
provide service on different ports. Therefore, the port number that is used by each
DRDA Server will need to be extracted from the configuration of each individual
DRDA Server. DB2 for OS/390 and DB2/400 typically use the DRDA standard port
number, 446, whereas DB2/UDB typically uses 50000 as the port number. Refer to
IBM DB2 Administrator and Installation guides for locating and changing these port
numbers for the DRDA Server. For additional information, consult your DB2 DBA or
system administrator.
8.2 Configuring TCP/IP
The following configuration example is for Microsoft Windows NT 4.0. Other
Microsoft Windows operating systems may have these panels in a different location or
may present them differently, but the required contents will be essentially the same.
You configure TCP/IP from the network configuration tool in the Microsoft Windows
Control Panel.
Configuring TCP/IP 8-1
Configuring TCP/IP
Select the Protocol tab and select TCP/IP Protocol. Then, click Properties to display
the Properties panel.
Figure 8–1 Network Configuration Tool
If the TCP/IP Protocol is not already installed, then click Add and then select the
TCP/IP Protocol.
Configuration consists of assigning a host name, an IP address, and a network mask to
a given network interface.
In the IP Address tab, use the drop-down list to select the adapter you will use. Your
network administrator can tell you whether you will be using DHCP or a static IP
address. If using a static IP, then you must enter the correct values for IP address,
subnet mask, and default gateway.
8-2 Oracle Transparent Gateway for DRDA Installation and User's Guide
Figure 8–2 TCP/IP Properties Panel
Configuring TCP/IP
Additional configuration consists of defining a name server IP address or creating
entries in the hosts file on the local system. Name server translate host names into IP
Addresses when queried on a particular host name. The hosts file provides this same
functionality, but in a non-network participating manner.
The Hosts file may be edited with a text editor of your choice. For example, in
Microsoft Windows NT, the file is located in:
C:\winnt\system32\drivers\etc\hosts
where C:\winnt is the Windows NT system root.
To use a name server, you must configure the TCP/IP to use DNS. Select the DNS tab
and enter a host name and domain name. Your network administrator will provide
these values. Click Add below the Domain Suffix Search Order box and enter the IP
Address of the name server. You may enter up to three name servers. Click OK.
Configuring TCP/IP 8-3
Configuring TCP/IP
Figure 8–3 Define a Name Server
For local configuration (in other words, the gateway and the DRDA Server are on the
same system), it may be desirable to use the loop-back address. The IP address
is 127.0.0.1 and is typically given the local name ("localhost" or "loopback") in the
Hosts file. Using the loop-back address reduces the amount of network overhead by
handling the traffic internally without actually talking to the network.
The gateway is configured for TCP/IP using the DRDA_CONNECT_PARM initialization
file parameter. In an SNA configuration, this parameter would be set to the Side
Information Profile name (name set in Figure 6–21 or Figure 7–17). In a TCP/IP
configuration, this parameter should be set to the IP address or Host name of the
DRDA Server, which should be followed by the Service Port number of that server. For
more information about the port number, refer to "Port Number" on page 8-1.
Note: When installing the gateway, you must choose either SNA
or TCP/IP for the networking interface. The DRDA_CONNECT_PARM
must be configured correctly for the chosen networking interface.
The rest of the DRDA-specific parameters are unrelated to the communications
protocol and may be set the same for either SNA or TCP/IP installations.
Example #1: Configuration for a DRDA Server on a host named 'mvs01.domain.com'
(or IP address of 192.168.1.2) with a Service Port number of 446.
DRDA_CONNECT_PARM=mvs01.domain.com:446
or
8-4 Oracle Transparent Gateway for DRDA Installation and User's Guide
Configuring TCP/IP
DRDA_CONNECT_PARM=192.168.1.2:446
Example #2: Configuration for a DRDA Server on the same host as the gateway with a
Service Port number of 446.
DRDA_CONNECT_PARM=localhost:446
or
DRDA_CONNECT_PARM=127.0.0.1:446
For additional information on configuring TCP/IP, refer to the Microsoft Windows
installation and configuration guides.
Configuring TCP/IP 8-5
Configuring TCP/IP
8-6 Oracle Transparent Gateway for DRDA Installation and User's Guide
9
Oracle Net
Oracle Net is an Oracle product providing network communication between Oracle
applications, Oracle Servers, and Oracle Gateways across different systems.
This chapter contains the following sections:
■Checklists for Oracle Net
■Oracle Net and SQL*Net Introduction
■Oracle Net Overview
■Configuring Oracle Net
■Advanced Security Encryption
■Setting Up Advanced Security Encryption for Test
■Testing Advanced Security Encryptions
9.1 Checklists for Oracle Net
Use the following checklists when you are installing and configuring Oracle Net.
9.1.1 Configuring Oracle Net
■Step 1: Modify the listener.ora file
■Step 2: Modify the tnsnames.ora file
9.1.2 Advanced Security Encryption
Use the following checklists for encryption.
9.1.2.1 Setting Up Advanced Security Encryption for Test
■Step 1: Set Advanced Security Encryption Parameters for the Gateway
■Step 2: Set Advanced Security Encryption Parameters
9.1.2.2 Testing Advanced Security Encryptions
■Step 1: Connect the Gateway and Oracle the Integrating Server
■Step 2: Reset Configuration Parameters on the Gateway
Oracle Net 9-1
Oracle Net and SQL*Net Introduction
9.2 Oracle Net and SQL*Net Introduction
Oracle Net provides connectivity to the Gateway through the use of Protocol
Adapters, SQL*Net, and the TNS Listener. Configuration of Oracle Net is backward
compatible with past versions of SQL*Net. A new facility called Heterogeneous
Services (HS) has been added to both Oracle Net and the Gateway to improve the
throughput of SQL*Net data. For additional information, refer to Oracle Database Net
Services Administrator's Guide and Oracle Database Heterogeneous Connectivity
Administrator's Guide.
9.3 Oracle Net Overview
Oracle Net is a required Oracle product supporting network communications between
Oracle applications, Oracle servers, and Oracle gateways across different CPUs or
operating systems. It also supports communication across different Oracle databases
and CPUs providing distributed database and distributed processing capabilities.
Oracle Net also enables applications to connect to multiple Oracle servers or gateways
across a network, selecting from a variety of communications protocols and
application program interfaces (APIs) to establish a distributed processing and
distributed database environment.
A communications protocol is a set of implemented standards or rules governing data
transmission across a network. An API is a set of subroutines providing an interface
for application processes to the network environment.
9.3.1 Distributed Processing
Dividing processing between a front-end computer running an application and a
back-end computer used by the application is known as distributed processing. Oracle
Net enables an Oracle tool or application to connect to a remote computer containing
an Oracle server or Oracle gateway.
9.3.2 Distributed Database
Several databases linked through a network, appearing as a single logical database, are
known as a distributed database. An Oracle tool running on a client computer or on an
Oracle server running on a host computer can share and obtain information retrieved
from other remote Oracle servers. Regardless of the number of database information
sources, you might be aware of only one logical database.
9.3.3 Terminology for Oracle Net
The following terms are used to explain the architecture of Oracle Net for Microsoft
Windows:
host is the computer the database resides on and that runs the Oracle server or
gateway.
client (task) is the application using an Oracle Net driver to communicate with the
Oracle server or gateway.
protocol is a set of standards or rules governing the operation of a communication
link.
driver is the part of Oracle Net supporting a given network protocol or
communication method.
9-2 Oracle Transparent Gateway for DRDA Installation and User's Guide
network is a configuration of devices and software connected for information
interchange.
9.4 Configuring Oracle Net
The gateway must be defined to the TNS listener, and a service name must be defined
for accessing the gateway.
9.4.1 Step 1: Modify the listener.ora file
Add an entry for the gateway to the listener.ora file. For example:
Refer to Appendix B, "Sample Files", for a sample listener.ora file.
Note: The PROGRAM=g4drsrv parameter is required. It specifies
to the listener the name of the gateway executable.
Configuring Oracle Net
9.4.2 Step 2: Modify the tnsnames.ora file
Add a gateway service name to the tnsnames.ora file on the system where your Oracle
integrating server resides. Specify the service name in the USING parameter of the
database link defined for accessing the gateway from the Oracle Database 10g server.
You can use the IPC protocol only if the Oracle integrating server and the gateway
reside on the same system. If you use the IPC protocol adapter, then add an entry like
this to tnsnames.ora:
linkname1 is the name used to define the database link referencing the gateway.
ORAIPC is the IPC key defined in the listener.ora file for the IPC protocol
sidname is the gateway SID, the same SID that you used for the entry in the
listener.ora file.
If you are using the TCP/IP protocol adapter, then add this entry to tnsnames.ora:
linkname2 is the name used to define the database link referencing the gateway
port is the default Oracle TCP/IP port number (1541)
hostname is the name of your host system
sidname is the gateway SID
Refer to "Sample Oracle Net tnsnames.ora File" on page B-2 for a sample tnsnames.ora
file. For more information about configuring Oracle Net, refer to the Oracle Database Net Services Reference and Oracle Database Net Services Administrator's Guide.
9.5 Advanced Security Encryption
Oracle Net supports the CHECKSUM command and the Export encryption algorithms.
The following sections describe a basic method of verifying this feature if it is used at
your site. The easiest way to determine if Advanced Security encryption is attempting
to work is to deliberately set wrong configuration parameters and attempt a
connection between the server and client. Incorrect parameters cause the connection to
fail.
After receiving the expected failure message, set the configuration parameters to the
correct settings and try the connection again. Encryption is working properly if you
receive no further error messages.
9.6 Setting Up Advanced Security Encryption for Test
The following procedures test Advance Security encryption by the method explained
earlier. The incorrect parameter settings produce error 12660
1. Set Advanced Security encryption parameters for the gateway
2. Set Advanced Security encryption parameters for the Oracle integrating server
Note: The international or export version of Advanced Security
encryption supports the following encryption types:
■des40
■rc4_40
9.6.1 Step 1: Set Advanced Security Encryption Parameters for the Gateway
Edit the Oracle Net configuration file on the Microsoft Windows system (gateway
system) to add the following parameters and values:
The value shown for SQLNET.CRYPTO_SEED is only an example. Set it to the value
you want. Refer to the Oracle Database Advanced Security Administrator's Guide for more
information.
9-4 Oracle Transparent Gateway for DRDA Installation and User's Guide
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.