This chapter is from the book
This chapter is from the book
This chapter is from the book
Address Spaces
The address spaces used in the operation of DB2 are
-
System services address space (SSAS)
-
Database services address space (DSAS)
-
Internal resource lock manager (IRLM)
-
Distributed Database Facility (DDF)
-
Stored procedure address space (SPAS)
-
Allied address spaces
Figure 2-1 shows the relationship among the address spaces DB2 uses.
)
Figure 2-1 Relationship between DB2 users and DB2-related address spaces
The system services address space, also called the Data System Control Facility (DSCF) address space, is the DSN1MSTR address space. The following subcomponents execute in the SSAS:
-
General command processor
-
Subsystem support
-
Agent services manager
-
Storage manager
-
Message generator
-
Initialization procedures
-
Instrumentation facilities
-
System parameter manager
-
Recovery manager
-
Recovery log manager
-
Group manager
-
Distributed transaction manager
This is critical, as it manages most of the activities in DB2. The database services address space, also called the Advanced Database Management Facility (ADMF) address space, is the DSNDBM1 address space. The following subcomponents execute in the DSAS:
-
Service controller
-
Data manager
-
Large-object manager (LOBM)
-
Data space manager
-
Relational data system (RDS)
-
Stored-procedures manager
-
Utilities (work with associated code in an allied address space)
-
Buffer manager
The DBM1 address space uses memory for several operations in DB2. The following output from a DB2 Performance Monitor report shows the DB2 objects that use memory in the DBM1 address space:
DBM1 STORAGE STATISTICS (MB) ------------------------------------ TOTAL GETMAINED STORAGE VIRTUAL BUFFER POOLS EDM POOL COMPRESSION DICTIONARY CASTOUT BUFFERS TOTAL VARIABLE STORAGE TOTAL AGENT SYSTEM STORAGE TOTAL AGENT LOCAL STORAGE RDS OP POOL RID POOL PIPE MANAGER SUB POOL LOCAL DYNAMIC STMT CACHE CTL BLKS LOCAL DYNAMIC STMT CACHE STMT POOL BUFFER & DATA MANAGER TRACE TBL VIRTUAL POOL CONTROL BLOCKS TOTAL FIXED STORAGE TOTAL GETMAINED STACK STORAGE STORAGE CUSHION TOTAL DBM1 STORAGE TOTAL NUMBER OF ACTIVE USER THREADS TOTAL STORAGE FOR ALL THREADS NUMBER OF PREFETCH ENGINES NUMBER OF DEFERRED WRITE ENGINES NUMBER OF CASTOUT ENGINES NUMBER OF GBP WRITE ENGINES NUMBER OF P-LOCK/NOTIFY EXIT ENGINES
Each DB2 subsystem has its own internal resource lock manager. The IRLM controls access to the application data and is used by DB2 as the lock manager to ensure the integrity of the data.
The Distributed Data Facility allows client applications running in an environment that supports Distributed Relational Database Architecture (DRDA) to access DB2 data. The DDF also allows for one DB2 subsystem to access data on another DB2 subsystem. Other relational database servers can be accessed if they support DRDA. TCP/IP and SNA (Systems Network Architecture) are the supported network protocols.
DDF permits up to 150,000 distributed concurrent threads to be attached to a single DB2 subsystem at a time. The following resource managers execute in the DDF services address space:
-
Data communications resource manager (DCRM)
-
Distributed data interchange services (DDIS)
-
Distributed relational data system manager (DRDS)
-
Distributed transaction manager (DTM)
The stored-procedure address space (DSN1SPAS) is established by DB2. SPAS provides an isolated environment in which to execute stored procedures.
To create new stored procedures in version 8 it is recommended that you use WLM (Workload Manager) address spaces.
The Workload Manager (WLM) component of z/OS manages address spaces for the execution of stored procedures and user-defined functions. These address spaces are called application environments. When an application calls a stored procedure or external user-defined function, DB2 schedules this work with WLM to run in a WLM-managed application environment. Each DB2 subsystem may have many defined application environments.
The allied address spaces communicate with DB2. The SPASs operate as allied address spaces. The following subcomponents execute in allied address spaces:
-
Attachment facilities: call attachments, CICS, IMS, recoverable resource manager services, TSO
-
Message generator (standalone only)
-
Subsystem support
-
Utilities: DDAS; standalone
Address Space Priority
To establish the z/OS address space dispatching priorities, the IRLM address space should be placed above IMS, CICS, and DB2, with DB2's MSTR and DBM1 address spaces placed above CICS. The following is a recommended priority listing:
-
MVS monitor with IRLM capabilities
-
IRLM
-
DB2 performance monitors
-
DBM1
-
MSTR
-
WLM-managed application environments
-
CICS
If the IRLM address space is not at the top of the dispatching priorities, DB2 locks will not get set and released without causing excessive wait time (see Chapter 16 for information on DB2 locks). A warning message will be issued if the IRLM is not above DBM1 at DB2 start-up.
It is important to pay attention to the dispatching recommendations of the vendors of the various performance monitors. Each vendor has one or more address spaces and always recommends specific dispatching priorities. If a performance monitor that can analyze problems in the IRLM is being used, dispatching IRLM higher than a DB2 and/or MVS monitor could be a problem. If a performance monitor can't get dispatched ahead of IRLM, you will not be able to find or analyze the problem.
Attachments
Attachment facilities provide the interface between DB2 and other environments. Only one attachment can be active within a program at any given time. Five attachment facilities can be used, depending on the environment in which the program will execute. The attachments are
-
Customer Information Control System (CICS)
-
Information Management System ( IMS)
-
Call Attach Facility (CAF)
-
Resource Recovery Manager Services Attachment Facility (RRSAF)
-
Time Sharing Option (TSO)
Each program runs in an allied address space. The DB2 attachment facility modules are called by the program, execute within the allied address space, and establish communication with the DB2 address spaces. When initialized, the attachment modules make the link to DB2, and agent control blocks are created in the DSNMSTR address space to control the program's DB2 processing.
When a program issues an SQL statement, the attachment modules are given control. The attachment programs prepare the request for DB2 and pass the request over to the DB2 address space. Results are passed back to the attachment programs, and any results are copied into the application storage areas.
Call Attach Facility
The DB2 Call Attach Facility is used for application programs that run under TSO or z/OS batch. The CAF is an alternative to the DSN command processor and provides greater control over the execution environment.
With the CAF, your application program can establish and control its own connection to DB2. Programs that run in z/OS batch, TSO foreground, and TSO background can use CAF.
IMS batch applications too can access DB2 databases through CAF, although that method does not coordinate the commitment of work between the IMS and DB2 systems. It is recommended that you use the DB2 Data Language/I batch support for IMS batch applications.
Programs using CAF can
-
Access DB2 from address spaces where there is no TSO, CICS, or IMS
-
Access the Instrumentation Facility Interface (IFI)
-
Access DB2 from multiple tasks within an address space
-
Control the connection to DB2 explicitly
-
Connect to DB2 implicitly, using a default subsystem ID and plan name
-
Receive a signal from DB2 on start-up or shutdown.
The Call Attach Facility is being slowly replaced by the more powerful RRS (resource recovery services) attachment facility.
Customer Information Control System
CICS is an application server that provides online transaction management for applications. You can use the CICS attachment facility to connect to DB2 from this environment. CICS facilitates access to DB2 data from the CICS environment. A CICS application can access both DB2 and CICS data; in the event of a failure, CICS coordinates the recovery between DB2 and CICS.
Once the DB2 subsystem has been started, DB2 can be operated from a CICS terminal. DB2 and CICS can be started independently of each other. The connection can also be made automatic. Figure 2-2 shows the relationship between DB2 and CICS. The CICS attachment facility manages multiple connections to DB2, called threads, that can be reused for improved performance.
)
Figure 2-2 Relationship of DB2 to CICS
Information Management System
The IMS database computing system includes a hierarchical database manager, a transaction manager, and middleware products for access to the IMS databases and transactions. In order to connect to DB2, you can use the IMS attachment facility, which receives and interprets requests for access to DB2 data via exit routines in the IMS subsystems. IMS can connect automatically to DB2 without operator intervention. You can make DB2 calls from IMS applications by using embedded SQL statements. DB2 also provides the database services for IMS-dependent regions with the IMS attachment facility. An IMS batch environment has support for DL/1 batch jobs to have access to both IMS (DL/1) and DB2 data.
IMS will also coordinate recoveries between DB2 and IMS in the event of a failure. You also have the option to include DB2 in the IMS Extended Recovery Facility (XRF) recovery scenario. Figure 2-3 shows the relationship between IMS and DB2.
)
Figure 2-3 Relationship between DB2 and IMS
Resource Recovery Services Attachment Facility
RRSAF is a DB2 subcomponent that uses z/OS transaction management and resource recovery manager services to coordinate resource commitment between DB2 and all other resource managers that also use z/OS RRS in a z/OS subsystem.
An application program can use the RRSAF attachment facility to connect to and use DB2 to process SQL statements, commands, or IFI calls. Programs that run in z/OS batch, TSO foreground, and TSO background can use RRSAF.
RRSAF uses z/OS transaction management and resource recovery manager services (z/OS RRS). With RRSAF, you can coordinate DB2 updates with updates made by all other resource managers that also use z/OS RRS in a z/OS system.
Programs that use RRSAF can
-
Run under UNIX system services, TSO, or batch
-
Use dynamic and static SQL Statements
-
Sign on to DB2 with an alternative user ID
-
Access DB2 from one or more tasks in an address space
-
Use the IFI
-
Control the exact state of the DB2 connection
-
Capture DB2 start-up and termination events
Programs using RRSAF can be run from almost every environment available under z/OS. The programs can be invoked from the command prompt in TSO, from a shell prompt under UNIX system services, and, like any non-DB2 program using the PGM specification, on the EXEC card in Job Control Language (JCL).
Each task control block (TCB) can have only one connection to DB2. Using RRSAF, this connection can be switched between tasks within the address space. It is also possible to directly connect to multiple DB2 susbystems and switch between them during execution, although this would limit the ability to move subsystems to alternate systems in a sysplex.
Time Sharing Option
TSO allows interactive time-sharing capabilities from local and remote terminals. The TSO attachment facility is used by the majority of TSO applications. TSO controls programs, also allowing noninteractive batch program execution. In order to connect to DB2, you can use the TSO CAF or the RRS (resource recovery services). Historically, the TSO attachment facility has been the most commonly used connection for TSO interactive and batch applications.
Using TSO, you can bind application plans and packages and execute several online functions of DB2. Figure 2-4 shows the relationship between DB2 and TSO. Application programs and databases can be created, modified, and maintained via the TSO attach. You can run in either the foreground or batch when accessing DB2.
)
Figure 2-4 Relationship between DB2 and TSO
Access to two command processors is allowed when using TSO:
-
DSN command processor
-
DB2 Interactive (DB2I)
The DSN command processor runs as a TSO command processor using the attachment facility. This command processor provides an alternative method for executing programs in a TSO environment that accesses DB2. This processor can be invoked from the foreground by issuing a TSO command or from batch by invoking the TMP (terminal monitor program) from an MVS batch job, passing the commands in the SYSTSIN data set to TMP. When DSN is running and DB2 is up, you can issue DB2 or DSN commands (covered later in this chapter).
The DB2I comprises ISPF panels that allow for an interactive connection to DB2 and invokes the DSN command processor behind the scenes. With this processor, you can invoke utilities, issue commands, and run SQL statements. DB2I is discussed in more detail later in this chapter.