Connectivity Supplement

DB2 for MVS/ESA

Figure 1 shows an MVS system running a single copy of DB2 for MVS/ESA. It is also possible to run multiple copies of DB2 for MVS/ESA on a single MVS system. To identify copies of DB2 for MVS/ESA within a given MVS system (or copies of DB2 for MVS/ESA within an MVS/JES complex), each DB2 system is given a subsystem name, a one- to four- character string unique within an MVS/JES complex. In Figure 1, the DB2 for MVS/ESA subsystem name is xxxx.

Three of the MVS address space names are prefixed by the DB2 for MVS/ESA subsystem name. These three address spaces make up the DB2 for MVS/ESA product.

Figure 1. MVS Address Spaces used by DB2 for MVS/ESA

Figure 1 shows the MVS address spaces involved in distributed database processing with DB2 for MVS/ESA. These address spaces work together to allow DB2 for MVS/ESA users to access local relational databases and communicate with remote DRDA systems. The purpose of each address space is as follows:

xxxxMSTR

The system services address space for the DB2 for MVS/ESA product responsible for starting and stopping DB2 for MVS/ESA, and controlling local access to DB2 for MVS/ESA.

xxxxDBM1

The database services address space responsible for accessing relational databases controlled by DB2 for MVS/ESA. This is where the input and output to database resources is performed on behalf of SQL application programs.

xxxxDIST

The portion of DB2 for MVS/ESA that provides distributed database capabilities; also known as the Distributed Data Facility (DDF). When a distributed database request is received, DDF passes the request to xxxxDBM1, so that the required database I/O operations can be performed. This book describes DDF in detail.

IRLM

The lock manager used by DB2 for MVS/ESA to control access to database resources.

VTAM

The SNA Communications Manager for the MVS system. DDF uses VTAM to perform distributed database communications on behalf of DB2 for MVS/ESA.

NETVIEW

The network management focal point product on MVS systems. When errors occur during distributed database processing, DDF records error information (also known as alerts) in the NetView hardware monitor database. System administrators can use NetView to examine the errors stored in the hardware monitor database, or provide automated command procedures to be invoked when alert conditions are recorded.

NetView can also be used to diagnose VTAM communication errors. For more information, see the Distributed Relational Database Architecture Problem Determination Guide.

Figure 1 does not show any SQL application programs. When an application program uses DB2 to issue SQL statements, the application program must attach to the DB2 for MVS/ESA product in one of the following ways:

TSO

Batch jobs and end users logged on to TSO are connected to DB2 for MVS/ESA through the TSO attach facility. This is the technique used to connect SPUFI and most QMF applications to DB2 for MVS/ESA.

CICS/ESA

When a CICS/ESA application issues SQL calls, the CICS/ESA product uses the CICS attach interface to route SQL requests to DB2 for MVS/ESA.

IMS/ESA

Transactions running under the control of IMS/ESA use the IMS attach interface to pass SQL statements to DB2 for MVS/ESA for processing.

DDF

The Distributed Data Facility is responsible for connecting distributed applications to DB2 for MVS/ESA.

CAF

The call attachment facility allows user-written subsystems to connect directly to DB2 for MVS/ESA.