Connectivity Supplement

DB2 Universal Database for OS/390

Figure 13 shows an OS/390 system running a single copy of DB2 Universal Database for OS/390. It is also possible to run multiple copies of DB2 Universal Database for OS/390 on a single system. To identify copies of DB2 Universal Database for OS/390 within a given system (or copies of DB2 Universal Database for OS/390 within a JES complex), each DB2 system is given a subsystem name, a one- to four- character string unique within the JES complex. In Figure 13, the DB2 Universal Database for OS/390 subsystem name is xxxx. Three of the OS/390 address space names are prefixed by the DB2 Universal Database for OS/390 subsystem name. These three address spaces make up the DB2 Universal Database for OS/390 product.

Figure 13. OS/390 Address Spaces used by DB2 Universal Database for OS/390

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

xxxxSPAS

The DB2 stored procedures address space.

xxxxMSTR

The system services address space for the DB2 Universal Database for OS/390 product responsible for starting and stopping DB2 Universal Database for OS/390, and controlling local access to DB2 Universal Database for OS/390.

xxxxDBM1

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

xxxxDIST

The portion of DB2 Universal Database for OS/390 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.

IRLM

The lock manager used by DB2 Universal Database for OS/390 to control access to database resources.

VTAM

IBM Communications Server for OS/390 SNA functions (VTAM). DDF can use SNA or TCP/IP to perform distributed database communications on behalf of DB2 Universal Database for OS/390. No address space is shown for TCP/IP in this diagram.

NETVIEW

The network management focal point product on OS/390 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 13 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 Universal Database for OS/390 product in one of the following ways:

TSO

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

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 Universal Database for OS/390.

IMS/ESA

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

DDF

The Distributed Data Facility is responsible for connecting distributed applications to DB2 Universal Database for OS/390.

CAF

The call attachment facility allows user-written subsystems to connect directly to DB2 Universal Database for OS/390.

[ DB2 List of Books | Search the DB2 Books ]