1 Introduction to OSDI Architecture

1.1 Overview

OSDI consists of several well-defined components. The first of these components is a common management layer that is shared by all Oracle products that are implemented under OSDI. Below this, separate components are provided for each Oracle product or type of product. OSDI currently has two product implementation components, one for the Oracle RDBMS and one for Oracle Net.

1.2 Subsystem

The common management layer of OSDI is implemented as a formal z/OS subsystem. It is not associated with any single Oracle product or product instance. One OSDI subsystem can support multiple Oracle database instances and multiple Oracle Net services. The term service group refers to a collection of database instances and network services that are managed by an OSDI subsystem.

The OSDI subsystem has no associated address space. When the subsystem is initialized (normally during z/OS IPL), its program code is loaded into system common storage and a few data structures are built, but no address spaces are started. Subsequent interaction with the subsystem is accomplished via z/OS system operator commands and via programmatic requests issued over the subsystem interface (SSI). No address spaces are created until Oracle products are started.

The OSDI subsystem is what z/OS calls a dynamic subsystem. This means that it does not have to be initialized at system IPL: it can be initialized at any time using the SETSSI ADD system operator command. Once initialized, the OSDI subsystem is present in the z/OS system until the next IPL. Because the OSDI subsystem is a dynamic subsystem, it can be deactivated (SETSSI DEACTIVATE) and activated (SETSSI ACTIVATE) at will. When a subsystem is deactivated, no commands can be issued to it, no new Oracle product address spaces can be started, and no new client connections can be made to product instances currently running. Currently-running product instances and any existing client connections are not disturbed.

Figure 1-1 OSDI Architecture

1.3 Services

The primary role of the subsystem is to manage services. A service is a named, configured instance of an Oracle product. Each Oracle database instance and each network service that you run under OSDI will be a separate service. One subsystem can manage as many services as you desire. It is not necessary to create multiple OSDI subsystems in order to run multiple database instances or to run multiple network services.

Services must be defined to the subsystem. This is done with an OSDI DEFINE command. While OSDI commands can be issued from a z/OS system console (or similar interfaces such as SDSF or Netview), service definition commands are fairly lengthy and change infrequently. A significant advantage is gained by placing service definition commands in the parameter file that is read during OSDI subsystem initialization. Among the items that are specified when a service is defined are the user-selected service name, the type of Oracle product, and the name of the JCL procedure that is invoked to start an address space for the service. After a service is defined, the definition persists for the life of the IPL. The service cannot be deleted or renamed, but it is possible to change certain parts of the service definition using an OSDI ALTER command.

Defining or altering services manipulates only data structures that belong to the subsystem. These actions do not cause the execution of any Oracle products. In order to run a product that is configured as a service, an OSDI START command must be issued. The OSDI START command is similar to the z/OS command of the same name: it causes a specified service to begin execution in a z/OS address space using the JCL procedure specified in the service definition. You must use the OSDI START command (not the z/OS command) to start services. OSDI-managed services cannot be executed as z/OS batch jobs or as independent started tasks or STCs.

After a service is started, its behavior and operation depend on the Oracle product and how that product is configured. In general, the subsystem keeps track of the operating state of each service. The primary operating states are inactive, starting, active, and stopping. A service is normally in starting and stopping states only briefly, from the time it is started until initialization is complete (the service becomes active) and from the time termination begins until it actually ends (the service becomes inactive). Only services that are active are available for applications to use. You can display the state of a service using the OSDI DISPLAY command.

1.4 Connections

The subsystem is responsible for processing OSDI-specific commands and for managing the definition and operation of services. It also is responsible for managing connections between z/OS address spaces, specifically between clients and services. In this context, the term client differs from the usual Oracle usage of the term. A client is any z/OS address space that issues requests to an OSDI-managed service via z/OS cross-memory services. This includes applications that you normally think of as clients, such as an Oracle application or utility that connects to a local z/OS Oracle database instance. It also includes applications that are less obvious: when the Oracle network service connects an inbound remote client to a z/OS Oracle database, the network service address space is a client of the database service in OSDI terms.

OSDI calls this process of connecting a client address space to a service address space a bind. Bind processing is internal to Oracle product operation and is not directly visible to applications or users. The bind request uses the z/OS subsystem interface (IEFSSREQ macro), which is why deactivating a subsystem makes its services inaccessible to new client connections, or in other words, to new binds. OSDI has two types of bind requests. One type is used only by Oracle products that have special requirements for managing connections to services, including Oracle Net and the Oracle Access Manager products. The other type of bind is a normal application bind used by customer applications and by Oracle tools and utilities running in TSO, batch, and UNIX System Services address spaces. While bind is not an external mechanism, security considerations that are in bind processing are both visible and important. Security considerations are described in the following section.

1.5 Security

OSDI has several integrated security features. They are implemented using the z/OS RACROUTE interface, which provides program access to the z/OS System Authorization Facility, or SAF. The discussions and examples in this manual are based on IBM's z/OS Security Server (RACF) product, but any product that fully supports SAF can be used.

OSDI provides security processing during the following actions:

• An OSDI command is issued

• An address space binds to an OSDI-managed service

• A user requests a connection to an Oracle RDBMS instance with SYSOPER or SYSDBA privileges

• Certain types of users log on to an Oracle RDBMS instance for normal application processing

Command and bind authorization checking are part of the subsystem. When an OSDI command is processed, the subsystem performs a check to see if the user or console that is issuing the command is authorized to do so. The check is based on a resource name consisting of the subsystem name and the command verb. Similarly, subsystem bind processing checks to make sure that the user, address space, or task that is issuing the bind is authorized to access the target OSDI service that is specified in the bind request. The bind authorization check distinguishes between the two different types of bind discussed in the previous section. This is because the managed connection type of bind carries certain privileges that should not be made available to normal applications.

The SYSOPER/SYSDBA authorization check is performed by the database instance to which the connection is being made and is performed in addition to any bind authorization check made by the subsystem. This check uses a resource name consisting of the OSDI subsystem name, the database service name, and a fixed suffix string (either OPER or DBA).

In the first three of these authorization tests, if the SAF response is an indication that the associated resource is not defined, then the request is allowed. This means that RACF (or comparable) resource definitions are mandatory if command, bind, and Oracle SYSOPER/SYSDBA access are to be subject to SAF-based authorization controls.

In the fourth of these authorization tests, Oracle provides optional SAF-based password authentication at Oracle logon time for certain types of users.

1.6 Database Service

Starting an Oracle database service with an OSDI START command creates a z/OS address space and executes the JCL procedure that is specified in the service definition. In z/OS terms, the service runs as a system address space (similar to a started task or STC). The JCL procedure contains a single step that executes the OSDI database region control program. A few JCL DD statements are required. The region control program reads an input parameter file that specifies the name of the Oracle RDBMS kernel load module and several OSDI-specific operating parameters. The region control program then loads the Oracle kernel code into the address space and initializes various internal facilities.

If the database service has been defined to use multiple address spaces, and if the operating parameters indicate that additional address spaces are to be started immediately, then those address spaces are started automatically when initialization of the first address space is complete. Each auxiliary address space appears as a new STC executing the same JCL procedure as the first address space. Depending on how the service was defined, the new address spaces may have the same jobname as the first, or each may have a distinct jobname containing a three-digit suffix number. In addition to being started automatically, auxiliary address spaces can be started manually by issuing repeated OSDI START commands for the service. Each START command (after the first one) starts one more auxiliary address space, up to a maximum number that was specified when the service was defined.

When a database service uses multiple address spaces, client sessions are distributed more or less uniformly across those spaces. Service address space selection is performed by the subsystem during the processing of a client bind request. This is completely transparent to client software. No mechanism exists for a client bind request to designate or control the server address space to which it is assigned. Once a client session is bound to a given address space, the client remains there until it either disconnects from the database or terminates. If multiple database connections are made from a single client address space (in, for example, a multi-tasking application or in one of the Oracle Access Manager products), then those connections are distributed among the service address spaces just as though they had come from different client address spaces.

The auxiliary address spaces of a multi-address-space service do not respond to operator commands. All command interaction with the service is through the first address space, referred to as AS1. After auxiliary address spaces are started, they cannot be stopped individually. The auxiliary address spaces terminate when the entire service is terminated. Operator interaction with a running database service uses the OSDI STOP command and the z/OS STOP (P) and MODIFY (F) system commands, which are processed only by AS1.

OSDI initialization of a database service does not include the generic Oracle database startup. With OSDI, that step (which is required to make the database instance usable by applications) is performed separately. After the service address space, or spaces, are fully initialized, Oracle SQL*Plus (or a comparable mechanism) must issue an Oracle startup request to complete the instance startup processing. Only one startup request is required regardless of the number of address spaces the service is using.

Database service address spaces can persist over multiple Oracle startup and/or shutdown requests. In other words, OSDI does not terminate the database address spaces when an Oracle database shutdown is performed.

1.7 Network Service

Like the database, an Oracle Net network service is started with an OSDI START command and executes as a system address space. It uses a different JCL procedure from the database service, executes a different program, and has different JCL DD statement requirements. The network service runs in a single address space only and does not require a separate startup step as is required by the database service. When the network service address space starts, it initializes network protocol tasks and other internal facilities and initiates listen operations for inbound clients on designated network endpoints.

The network service must be running to support both inbound (remote) client connections to z/OS servers. (Outbound clients on z/OS--ones who are connecting to remote Oracle instances--interact directly with the TCP/IP protocol rather than using the network service. ) Some important changes exist in the way that inbound connections to z/OS servers are processed.

OSDI simplifies the networking implementation on z/OS and makes it behave in a manner more similar to Oracle Net on other platforms. Regardless of which z/OS database servers are to be accessed, the network service listens for inbound clients on a single endpoint for each protocol. Clients that are connecting via a given protocol specify the target z/OS server using a SID parameter that is part of the Oracle network address string. The network service does not need to know in advance which servers will be accessed by inbound clients because the network service locates servers using the SID. Nothing needs to be done to a database server to prepare it for access by network clients.