Connectivity Supplement
Figure 13 shows an OS/390 system running a single copy of DB2 for OS/390. It is
also possible to run multiple copies of DB2 for OS/390 on a single system. To
identify copies of DB2 for OS/390 within a given system (or copies of DB2 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 for OS/390 subsystem name is xxxx.
Three of the OS/390 address space names are prefixed by the DB2 for OS/390
subsystem name. These three address spaces make up the DB2 for OS/390 product.
Figure 13. OS/390 Address Spaces used by DB2 for OS/390
Figure 13 shows the OS/390 address spaces involved in distributed database processing
with DB2 for OS/390. These address spaces work together to allow DB2 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 for OS/390 product
responsible for starting and stopping DB2 for OS/390, and controlling local
access to DB2 for OS/390.
- xxxxDBM1
- The database services address space responsible for accessing relational
databases controlled by DB2 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 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 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 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
for OS/390 product in one of the following ways:
- TSO
- Batch jobs and end users logged on to TSO are connected to DB2 for OS/390
through the TSO attach facility. This is the technique used to connect SPUFI
and most QMF applications to DB2 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 for OS/390.
- IMS/ESA
- Transactions running under the control of IMS/ESA use the IMS attach
interface to pass SQL statements to DB2 for OS/390 for processing.
- DDF
- The Distributed Data Facility is responsible for connecting distributed
applications to DB2 for OS/390.
- CAF
- The call attachment facility allows user-written subsystems to connect
directly to DB2 for OS/390.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]
[ DB2 List of Books |
Search the DB2 Books ]