| Oracle® Transparent Gateway for DB2 Installation and User's Guide 10g Release 2 (10.2) for IBM z/OS (OS/390) Part Number B16220-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Transparent Gateway for DB2 Installation and User's Guide 10g Release 2 (10.2) for IBM z/OS (OS/390) Part Number B16220-02 |
|
|
PDF · Mobi · ePub |
This chapter is divided into two sections. The first section describes the architectural differences between MPM and OSDI with emphasis on administration and configuration considerations when migrating or upgrading to the Oracle9i version of the gateway. The second section describes how you migrate from a pre-Oracle Database 10g MPM gateway to the new Oracle Database 10g OSDI gateway.
OSDI is new Oracle software specific to IBM z/OS. It provides a z/OS execution environment for certain Oracle products. Prior to OSDI, TG4DB2 and Oracle Net were supported by separate subsystems called MPM and TNS, respectively. OSDI completely replaces both MPM and TNS with new z/OS-specific software. The supported Oracle products are the same, however, and their generic product behavior (as viewed by application programs) is unchanged.
With OSDI, z/OS subsystems are no longer associated with any single Oracle product or product instance. An OSDI subsystem can support multiple Oracle database instances, multiple gateway instances, and multiple Oracle Net services.
The following sections discuss the significant changes between an MPM and an OSDI configuration.
With OSDI, z/OS subsystems are no longer associated with any single Oracle product or product instance. An OSDI subsystem can support multiple Oracle database instances, multiple Oracle Net services, and multiple gateway services. An OSDI subsystem has no associated address space. Refer to "Configuring and Initializing an OSDI Subsystem" for a detailed description of the differences when configuring and initializing an OSDI subsystem.
An OSDI gateway instance runs under the control of the OSDI subsystem. See "Configuring a Gateway Service" for a detailed description of the differences as well as special considerations when running an Oracle gateway under OSDI.
The Network Service replaces the TNS facility and also runs under the control of the OSDI subsystem. The OSDI network service simplifies the networking implementation of the Oracle database service on z/OS and is implemented to be very similar to Oracle Net on other platforms. Each gateway no longer has to maintain its own listener as a network endpoint. See the appropriate section in this chapter for a detailed description of the differences as well as special considerations when running Oracle Net under OSDI:
The SQL*Net V1 style cross memory connect string (for example, W:sid) has been desupported with this release of Oracle Database 10g for z/OS. Refer to the migration chapter of the Oracle Database User's Guide for IBM z/OS (OS/390) for further details.
With OSDI, both MPM and TNS have been superseded. All MPM-specific and TNS-specific commands and messages are obsolete.
The following items discuss the differences in the way the gateway generates trace and log output.
Under OSDI, trace files can be written to spool files or disk data sets, as under MPM. This is specified using the TRACE_DSNAME gateway region parameter. See "TRACE_DSNAME | TDSN" on page 5-14 for a detailed description of the TRACE_DSNAME parameter.
Alert logs are written to a spool or disk file as specified by the SYSPRINT DD statement. If the SYSPRINT DD statement is omitted, then OSDI dynamically allocates a spool file for the alert log during service startup and writes a message to the system log identifying the system-generated DD name for the allocation. If you specify a disk data set for SYSPRINT, and if an error occurs while it is being written (including an out-of-space condition), then OSDI closes SYSPRINT, dynamically allocates a spool file, and begins writing to it.
The collection of the gateway instances, database instances, and network services managed by an OSDI subsystem is called a service group. OSDI subsystems are dynamic z/OS subsystems that do not have to be initialized at system IPL and can be initialized at any time. Once initialized, the OSDI subsystem remains in the z/OS system until the next IPL. As a dynamic subsystem, an OSDI subsystem can be activated and deactivated at will.
In contrast to MPM and TNS, OSDI-managed services cannot be executed as z/OS batch jobs or as independent started tasks, or STCs. Refer to "Postinstallation Steps" on page 4-4 for details on configuring and initializing an OSDI subsystem.
When migrating from MPM, avoid using the same subsystem name as any MPM or TNS subsystem that you have been running, even if you will not be using those subsystems after the OSDI installation. Unlike MPM and TNS, local OSDI clients do not normally need to be given, or need to specify, the OSDI subsystem name when connecting to a server. Reusing an MPM or TNS subsystem name therefore provides no particular benefit.
To run an Oracle gateway instance under OSDI, you must define the instance as a service using the OSDI DEFINE SERVICE command. You do this when converting an existing MPM-based instance to OSDI. In addition to defining the service, a few other items must be set up before the service can be started: a JCL procedure, several parameter files, and possibly security resource definitions. After these are in place, you can start the service, which creates one or more address spaces based on controls that you have specified.
Because OSDI gateways are not implemented as individual subsystems, OSDI gateways are no longer identified by subsystem names; instead, they are identified by SIDs. The SID is the OSDI Service Identifier that is used to identify the gateway. Under OSDI, the SID is defined during gateway service definition. A gateway service must be defined with a service name and optionally a SID. The service name is the default for the SID if the SID is not specified.
A JCL procedure name is specified during gateway service definition. The JCL procedure must then be created before the gateway service is started. Note that JCL and load library changes should not be made while a gateway service is active. The PARM parameter of the EXEC JCL statement is not used by the OSDI gateway instance program.
The new ORA$FPS DD statement specifies an input file containing OSDI-specific file management parameters. Refer to "File Processing Considerations" for further details.
OSDI simplifies the networking implementation on z/OS and makes it behave in a manner similar to Oracle Net on other platforms. The Oracle Net master task MPMTNS is no longer needed in any of the OSDI gateway address spaces in order to access the OSDI gateway. For further details on configuring Oracle Net under OSDI, refer to Chapter 6, "Oracle Net". Further descriptions of Oracle Net differences under OSDI can be found in the Oracle Net or Network Service section of this chapter.
OSDI processing of z/OS data sets that are used by the gateway differs significantly from that in MPM. The major visible changes include the following:
Allocation (creation) specifications and other file processing controls are supplied to the gateway in an input parameter file, the ORA$FPS DD statement. Keyword parameters are used to specify, by type of file, things such as SMS classes, allocation unit and volume, and so on. Each of the major types of files that is used by the gateway can be separately managed: gateway trace data sets and network trace data sets.
OSDI operating commands are used to start, stop, and display OSDI services. These commands can be issued through the z/OS command interface, either automatically (for example, COMMANDxx member of SYS1.PARMLIB) or manually through a console interface such as SDSF. All MPM commands and messages are obsolete and superseded by OSDI commands and messages. There is no OSDI equivalent to the MPMCMD command for TSO. A console interface such as SDSF must be used to issue OSDI commands from TSO. OSDI commands may also be issued through the OSDI program interface by a management component such as Oracle Enterprise manager agent. Operating commands are also permitted in the service group configuration file.
The OSDI START command must be used to start the gateway service. The OSDI START command is used to cause a gateway service to begin execution using the JCL procedure specified in the service definition. The OSDI START command (not the z/OS command) must be used to start services. Unlike MPM, OSDI-managed services cannot be executed as z/OS batch jobs or as independent started tasks or STCs.
The network service replaces the TNS facility and is started with an OSDI START command. The OSDI network service simplifies the networking implementation of the Oracle gateway service on z/OS and is implemented to be very similar to Oracle Net on other platforms.
Each gateway instance no longer has to maintain its own listener as a network endpoint. As a result, each gateway instance does not represent a distinct network address (for example, TCP/IP host name and port) that a client had to know to connect to that gateway. Clients connect to target z/OS gateway in the same manner as they connect to Oracle servers on other platforms by specifying the SID parameter that is part of the Oracle network address string.
The Network Service is configured as an OSDI service using the OSDI DEFINE SERVICE command. Like other OSDI services, the Network Service is defined with a service name and SID (defaults to service name). Unlike TNS, the Network Service SID is used to identify the Network Service to inbound clients. The Network Service SID must be four characters or less. The Oracle Net JCL procedure name must have an associated z/OS userid in order to use TCP/IP, which is controlled by z/OS UNIX System Services (USS). The associated z/OS userid must have an OMVS RACF segment (or equivalent, if a product other than RACF is used) if the installation is not using a default OMVS segment.
The OSDI START command must be used to start the network service. The OSDI START command is used to cause a network service to begin execution in its z/OS address spaces using the JCL procedure specified in the service definition. The OSDI START command (not the z/OS command) must be used to start services. Unlike TNS, OSDI-managed services cannot be executed as z/OS batch jobs or as independent started tasks or STCs. All TNS commands and messages are obsolete and superseded by OSDI commands and messages. Refer to Chapter 6, "Oracle Net" for details about operating Oracle Net Network Services.
SNS/TCPaccess is no longer supported as a separate Oracle Net driver. Support is provided through the HPNS interface of the IBM TCP/IP driver.
IXCF is no longer supported as a separate Oracle Net for z/OS protocol. IXCF can be supported through IBM TCP/IP, in which case, Oracle Net IBM TCP/IP protocol can be used.
Unlike TNS, the OSDI Network service will listen for multiple OSDI Oracle gateways on the same port number but cannot listen on multiple ports The TNSNAMES.ORA file entries that are being used by remote clients may need to be changed in order to reflect a new port number. Also, for OSDI, the gateway SID must be specified in the connect string for all inbound connections. See Chapter 6, "Oracle Net" for a description of configuring and administering Oracle Net with OSDI. Also refer to the migration chapter of the Oracle Database User's Guide for IBM z/OS (OS/390) for a detailed discussion of migration considerations for using Oracle Net with OSDI.
This section describes how to migrate from MPM-based gateways to the OSDI gateway. Moving to Oracle with OSDI from MPM-based Oracle and TNS-based Net is straightforward for most installations. This section of the chapter outlines the considerations in such a move, with references to detailed topic coverage in other chapters of this manual and in Oracle Database 10g for z/OS documentation.
This section lists the gateway behavior differences between releases.
Here are the steps required to upgrade or migrate your existing MPM-based gateway to the new Oracle Database 10g OSDI-based Transparent Gateway for DB2. When possible, you should follow the links back to the detailed description of each step.
Before any other upgrade steps will work, the subsystem must be defined to z/OS. This step is described in detail in "Postinstallation Steps" on page 4-4.
Create a JCL procedure for starting the service and place it in a system procedure library PDS. (The procedure library must be one that can be accessed without a JCLLIB statement.) Make sure that an appropriate z/OS user ID will be associated with address spaces that are started by using the procedure. Create the parameter files for the gateway program and save them as members of a PDS or as DSORG=PS data sets. Requirements for the JCL and for the region parameters are described in "Step 9: Edit the PARMLIB Members" on page 5-35.
Create and configure the OSDI Net Service as described in Chapter 6, "Oracle Net". Pay particular attention to the TNSNAMES entries and ensure that entries are updated to include SID parameters.
Perform installation required security steps for the OSDI subsystem and the gateway to DB2 connections. The OSDI security steps are covered in "Step 10: Associate User IDs with Services" on page 5-37. The gateway to DB2 security steps will depend on your current connection level security situation.
The 10g DB2 Gateway completely changes the way that DB2 security is done. If you modified the G4AUTH or DB2AUTH exits previously, these are no longer used.
The 10g DB2 Gateway uses the G4RRSAF Gateway logon exit, and does not modify the DB2 logon exits (as was done in the DB2 Gateway 9.2 and earlier releases).
If you had custom modifications to G4AUTH for the DB2 Gateway 9.2 or earlier and want to maintain these changes, they will have to be made to the new G4RRSAF exit. This is supplied in the SRCLIB in source form as G4SIGNON. Instructions are in chapter 7 for modifying the gateway logon exit.
In addition to the security exits discussed above, you must ensure that the date user exits are also available to the new gateway if they have been implemented in the current MPM-based gateway. This procedure is covered in "Step 4: Make Authorization and Local Date Exits Available to DB2" on page 5-28.
The DB2 environment must now be upgraded so that the Oracle packages, plan, views, and tables are at the level expected by the gateway. The necessary steps are documented in detail at:
Step 5: Run the Scripts to Create Required Tables and Views in DB2 on page 5-29
Step 6: Bind the DB2 Package on page 5-30
Step 7: Bind the DB2 Plan on page 5-32
Step 8: Grant EXECUTE on DB2 Plan on page 5-35
You can create multiple gateway services by defining a new service with a different service name and a different SID. The gateways will share the same subsystem, but all parameters, including the DB2 region they connect to, can be different. The steps required are a subset of the above steps.
The first step is the same as Step 2 above, paying particular attention that the service name and the SID are unique.
If your new gateway service is connecting to the same DB2 region as your existing gateway, then skip to Step 7 above. If not, then skip to Step 4 and execute each step as before.
You can continue to run MPM-based Oracle instances and TNS network services during your transition to OSDI. However, you must be aware of the limitation with database links (distributed access) between Oracle and/or gateway instances on the same z/OS system. Cross-memory database links (in either direction) between MPM and OSDI instances are not supported. If you have a requirement for such distributed access, then you will need to use TCP/IP instead of cross-memory access. Doing this requires running both OSDI Oracle Net and TNS with distinct TCP endpoint definitions.
TNS and OSDI NET Communication
An example of this type of MPM-to-OSDI connection is as follows:
The TNSNAMES entry defined to the OSDI Oracle instance to access the MPM-based gateway is:
G4XXMPM =
(DESCRIPTION=
(ADDRESS= (PROTOCOL=TCP) (HOST=MVS.TCP.IP.ADDR) (PORT=3998) (SSN=NET))
(HS=))
where PORT would be the port number that MPM TNS is listening on for the MPM gateway, and SSN is the SID of the OSDI NET.
The TNSNAMES entry defined to the MPM Oracle instance to access the OSDI-based gateway is:
G4XXOSDI =
(DESCRIPTION=
(ADDRESS= (PROTOCOL=TCP) (HOST=MVS.TCP.IP.ADDR) (PORT=4998) (SSN=TNS)
(HS=)
(CONNECT_DATA=(SID=G4X1))
where PORT would be the port number that OSDI NET is listening on for all defined OSDI services in its service group, SID is the SID of the OSDI gateway, and SSN is the SSN of the MPM TNS.
The DBLINK defined to the MPM-based Oracle instance to access the OSDI-based gateway would be:
Create database link g4osdi connect to scott identified by tiger using 'G4XXOSDI';
The DBLINK defined to the OSDI-based Oracle instance to access the MPM-based gateway would be:
Create database link g4mpm connect to scott identified by tiger using 'G4XXMPM';
In release 10g of the Oracle Transparent Gateway for DB2, there are no DB2 security exits installed in the DB2 subsystems. Therefore, release 10g of the gateway can coexist with any prior releases. You can leave pre-10g DB2 security exits installed in the DB2 subsystems. They are not used by the 10g gateway.
The DB2 date exit (DSNXVDTX) is compatible with all prior releases of the gateway. If you want to use this optional feature, then use the one from the10g distribution in your DB2 subsystem.
|
 Copyright © 1999, 2006, Oracle. All rights reserved. Legal Notices |
|