1 Introduction

Oracle Application Server connects to a Virtual Sequential Access Method (VSAM) system through the Oracle Application Server Adapter for VSAM (OracleAS Adapter for VSAM). The OracleAS Adapter for VSAM provides connectivity and runs interactions on a VSAM system. This chapter provides an overview of the feature and architecture of OracleAS Adapter for VSAM.

OracleAS Adapter for VSAM Overview

The OracleAS Adapter for VSAM models VSAM as a simple database with an SQL front end. The adapter is native to the data source and IBM OS/390 or z/OS system, providing direct access that results in improved performance.

OracleAS Adapter for VSAM includes the following features:

Captures and maintains a metadata schema for VSAM by importing COBOL copybooks and transforming them into mapping definitions for Oracle Connect for VSAM on the IBM z/OS system and by associating the data structures with specific physical files.

Full-fledged query processor and optimizer that runs SQL against the VSAM data with full support for VSAM data types such as arrays.

Uses an enterprise application integration (EAI) model. Users of a requesting application can model the interactions that they want implemented, specifying what each interaction does, when it occurs and the inputs and outputs expected for each interaction.

Implements interactions as parameterized SQL with the parameters forming the input record, and with the output (in cases where there is an output) aggregated into an XML document forming the output record.

Enables you to access VSAM data managed by CICS or directly.

Does support global transactions under CICS and can fully participate in a distributed transaction.

VSAM Data

VSAM is an IBM disk file storage scheme first used in S/370 and VS (Virtual Storage). VSAM comprises the following three access methods:

Keyed Sequential Data Set (KSDS)-indexed file

Relative Record Data Set (RRDS)-relative file

Entry Sequenced Data Set (ESDS)-sequential file

These VSAM access methods are supported by the adapter

VSAM has no built-in metadata schema although a VSAM file does include information about its type (KSDS, RRDS, or ESDS) and index definition (KSDS only). Typically, VSAM is used by COBOL programs, either standalone (also known as batch programs) or CICS transactions. The VSAM record definitions are typically maintained within the COBOL code as COBOL copybooks.

Accessing VSAM Data

OracleAS Adapter for VSAM enables access to VSAM data under CICS or directly. If the VSAM cluster is managed by CICS, you can still access VSAM data directly to improve performance when the VSAM data is managed by CICS but access to it is read only, and there is no risk that changes are buffered by CICS while the read is performed.

Oracle Connect: Oracle Connect runs on the legacy system and handles requests from the J2CA 1.5 VSAM adapter, that runs within Oracle Application Server Containers for J2EE (WebLogic).

Oracle Studio: Oracle Studio is the configuration tool for Oracle Connect. Configuration tasks using Oracle Studio are performed on a Windows or Linux computer. Oracle Studio uses perspectives that enables you to generate specific information necessary to model OracleAS Adapter for VSAM.

The following figure illustrates the components of OracleAS Adapter for VSAM:

Integration Flow from Oracle Application Server to the Legacy Application

The J2CA 1.5 VSAM adapter converts the J2CA interaction invocation received from Oracle Application Server to the XML format and passes the XML format to Oracle Connect on the legacy server. The daemon listens for the request coming from the J2CA 1.5 VSAM adapter client and assigns a server process to handle the request. The properties of the server process, such as connection pooling requirements, are defined by a workspace definition within the daemon. The server process includes an instance of the application engine, which converts the XML format into native structures understandable by VSAM and passes the converted XML to the back-end adapter. The back-end adapter builds an interaction based on the metadata for the back-end adapter stored in the repository and the incoming converted XML, and passes it to the legacy application. The results of this execution are passed back to the application engine, using the back-end adapter, where these results are converted to XML and passed back to the client.

Scripting on this page enhances content navigation, but does not change the content in any way.