DB2 Address Spaces in Depth

From one subsystem to several address spaces

An address space is a z/OS execution environment with its own virtual storage. Splitting DB2 into multiple address spaces creates boundaries for storage, dispatching, recovery, monitoring, and problem determination. The split is functional rather than a split into independent databases: all the core spaces cooperate as one subsystem and serve the same catalog, directory, logs, table spaces, and application workload.

The four-character subsystem name is commonly written as ssnm in IBM material. Suffixes identify the principal DB2 spaces. For example, a subsystem named DB2P normally displays DB2PMSTR, DB2PDBM1, and DB2PDIST. Documentation often uses DSNMSTR and DSNDBM1 as generic examples; DSN is a placeholder prefix, not proof that every installation literally runs jobs with those names. The started-task procedure named in a z/OS START command may also differ from the resulting job name.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SDSF DA - conceptual started-task view (SSID DB2P)
 
JOBNAME   TYPE   STATUS   PURPOSE
DB2PMSTR  STC    ACTIVE   DB2 system services
DB2PDBM1  STC    ACTIVE   DB2 database services
DB2PDIST  STC    ACTIVE   DDF distributed services
DB2PIRLM  STC    ACTIVE   Separate IRLM lock manager
DB2PWLM1  STC    ACTIVE   Example WLM application environment
 
Generic IBM naming:
  ssnmMSTR -> DSNMSTR pattern -> DB2PMSTR when ssnm is DB2P
  ssnmDBM1 -> DSNDBM1 pattern -> DB2PDBM1 when ssnm is DB2P
  ssnmDIST -> DSNDIST pattern -> DB2PDIST when ssnm is DB2P
 
Always verify procedure and job names in the site's operations runbook.

Address-space operational reference

MSTR: ssnmMSTR system services

The master address space, ssnmMSTR, is DB2's system services address space. It is frequently described as the control center because subsystem-level coordination is concentrated there. MSTR participates in starting and stopping DB2, processing system control activity, coordinating recovery, and managing logging functions. It owns neither the application's program nor the database buffer pools, but the subsystem cannot operate coherently without it.

Logging is especially important. An updating unit of work must create log records before changed database pages can safely reach disk. At COMMIT, DB2 must make the required log information durable according to its write-ahead logging rules. If a transaction rolls back, recovery processing uses those records to undo its changes. If DB2 restarts after an interruption, system services coordinate log-based recovery so committed work remains and incomplete work is handled correctly. The active logs and archive logs are data sets, not storage embedded inside MSTR, but MSTR is central to the services that manage them.

What operators associate with MSTR

• Startup and shutdown messages, subsystem command processing, and overall state changes
• Log management, checkpoints, restart processing, and recovery-oriented coordination
• Communication and synchronization with DBM1, DIST, IRLM, and attached workloads
• A failure whose effect can be subsystem-wide rather than limited to one application

“System services” is the precise functional name; “MSTR” is the familiar address-space suffix. Older diagrams may use SSAS, meaning system services address space. These labels refer to the same side of the architectural division and should not be confused with database services in DBM1.

DBM1: ssnmDBM1 database services

The ssnmDBM1 address space supplies database services. Its virtual storage contains the DB2 buffer pools that cache table-space and index pages. It also supports core relational processing and data management: finding rows through access paths, requesting synchronous reads or prefetch, applying updates in buffers, scheduling deferred writes, managing data and index structures, and maintaining thread-related database resources.

Calling DBM1 “the SQL engine” is useful for beginners, but do not interpret that phrase as saying every CPU instruction for an SQL request is charged only to the DBM1 started task. DB2 work can execute under application, enclave, stored procedure, and DB2 service contexts, and accounting classifications matter. Architecturally, however, DBM1 is the central database-services region: it owns the major shared data structures and services that turn an access path into page and row access.

Buffer-pool and data-path work

When a needed page is already in a buffer pool, DB2 can use it without a disk read. When it is absent, DBM1 services arrange I/O and may use sequential, list, or dynamic prefetch to bring useful pages in efficiently. An UPDATE changes a page in memory and marks it unavailable for simple reuse until write rules are satisfied. Deferred write engines later externalize changed pages, while write-ahead logging ensures the corresponding log records are secure first. This is why buffer-pool hit ratios, prefetch activity, I/O suspension time, and deferred-write thresholds are DBM1-centered operational topics.

Database services is not the same as storage on disk

DBM1 does not contain the permanent table data inside its private memory. VSAM data sets hold table spaces and indexes; buffer pools hold cached copies of their pages. A restart can reconstruct a consistent state from persistent data and log records. Keeping that distinction clear helps explain why losing an address space is different from losing a data set.

DIST: the distributed address space and DDF

The Distributed Data Facility (DDF) runs in ssnmDIST. It is DB2's distributed entry point for remote DRDA clients. Typical clients include Java applications using JDBC, products using ODBC or CLI drivers, remote DB2 systems, and middleware connecting over TCP/IP. DIST works with communications services, authenticates and represents remote users according to configuration, manages distributed connections and threads, and sends results and SQL diagnostics back across the network.

DIST is not a second database engine. After DDF accepts a request and creates or reuses an eligible distributed thread, the SQL request uses the same underlying database services as local work. DBM1 accesses buffered pages, IRLM manages locks, and DB2 logging protects changes. Consequently, high DIST CPU can indicate connection or network-facing processing, while high DBM1 I/O time can still be caused by SQL that originally arrived through DIST.

DDF lifecycle and operations

• DDF availability is controlled separately enough that local applications can be healthy while remote connections fail.
• Operators check the DDF started state, listening ports, location name, TCP/IP health, active connections, and distributed threads.
• Connection pooling can leave many connections established while only some have active DB2 work.
• A remote timeout may come from the network, pool, DDF limits, DB2 locking, or slow SQL; the DIST job name alone does not identify the cause.

IRLM: a separate lock manager address space

The Internal Resource Lock Manager (IRLM) runs separately from MSTR and DBM1. DB2 asks IRLM to obtain, convert, and release locks on resources such as table spaces, partitions, pages, rows, and application-defined lock names. Locks protect consistency while many local and distributed transactions use the same objects.

If a requested lock conflicts with one already held, the requester usually waits. IRLM tracks this ownership and wait relationship. A timeout occurs when a requester waits beyond a configured interval. A deadlock is different: two or more units of work form a cycle in which each waits for a resource held by another. IRLM detects the cycle, and DB2 chooses a victim whose work is rolled back to break it.

In a DB2 data sharing group, locking must extend beyond one member. IRLM participates in global lock management using coupling-facility lock structures so members agree about cross-system resource ownership and interest. This makes IRLM health and connectivity essential even when its CPU usage looks modest.

Operational distinction: dependency, not suffix

IRLM is not normally named ssnmIRLM by a universal rule. It has an installation-defined started-task procedure and identifier. Runbooks specify which IRLM belongs to each DB2 member and the proper start sequence. The practical rule is simple: a DB2 member needs its matching IRLM available before normal database work can proceed.

Stored procedure address spaces: classic SPAS

An external stored procedure contains application code that DB2 invokes in response to CALL. Running arbitrary language code inside a core DB2 region would expose critical engine services to application failures, storage errors, and unpredictable execution time. DB2 therefore uses separate execution environments for external procedures and many external user-defined functions.

Historically, DB2 provided a classic stored procedure address space commonly called SPAS, often illustrated as ssnmSPAS. Multiple routines could share this managed region. The model gave routines a boundary outside DBM1, but one shared region was less flexible for separating workloads, applying different service goals, and scaling independent classes of procedures. SPAS remains important when reading old manuals, messages, migration plans, or long-lived site documentation, but it is not the preferred design for modern external routines.

WLM stored procedure address spaces: the modern model

Modern external procedures and UDFs normally run in address spaces associated with a z/OS Workload Manager (WLM) application environment. A routine's definition identifies an environment, and the environment identifies a site-defined startup procedure. WLM can start address spaces when work arrives and manage them in accordance with service policies. These jobs do not have one universal ssnm suffix; the names reflect local WLM definitions.

Why WLM is operationally better

• Isolation: separate application environments can keep unrelated routine libraries and failures apart.
• Classification: z/OS can pursue different response-time or velocity goals for different routine workloads.
• Scalability: an environment can use multiple address spaces rather than forcing every routine through one classic shared SPAS.
• Control: operators can quiesce, refresh, or diagnose a routine environment without treating it as the core DB2 engine.

WLM does not remove DB2 from the call path. DB2 receives CALL, resolves the procedure, checks authorization, and dispatches the external execution request. The procedure runs in its WLM region and communicates with DB2. SQL issued by the procedure still requires DBM1 data services, IRLM locks, and normal logging. Configuration details such as the startup procedure, NUMTCB choices, language runtime, libraries, and security identity can affect concurrency and reliability.

How an SQL request flows through the spaces

Begin with the entry point. A local COBOL batch program, CICS transaction, IMS program, or TSO tool uses an attachment facility from an allied address space. A remote client enters through DIST/DDF. In both cases, DB2 establishes a thread that represents the application's work and authorization context.

DB2 interprets the statement and uses its package and access path. Database services in DBM1 locate index and table pages and arrange I/O when pages are not buffered. Before protected data is read or changed, DB2 asks IRLM for the locks required by the access path and isolation level. An updater generates log records through DB2 system and log services associated with MSTR. At COMMIT, locks are released according to their duration, resources become reusable, and the client receives completion status.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
LOCAL REQUEST
  COBOL batch / CICS / IMS / TSO
               |
               | attachment facility creates a DB2 thread
               v
          +---- DB2 request coordination --------------------+
          |                                                   |
          v                                                   v
  ssnmDBM1 database services --------------------------> IRLM
  - SQL/access-path services                              - acquire locks
  - buffer-pool lookup and I/O                            - record waits
  - table/index page processing                           - detect deadlocks
          |
          +-----------------> ssnmMSTR system services
                              - logging and recovery control
                              - subsystem coordination
 
REMOTE REQUEST
  JDBC / ODBC / remote DRDA client
               |
               v
       ssnmDIST (DDF) -> distributed thread -> same DBM1 / IRLM / MSTR services
 
EXTERNAL PROCEDURE
  CALL -> DB2 dispatch -> WLM application-environment AS
                         -> procedure SQL returns to DB2 services

A detailed UPDATE example

1. A CICS transaction issues an UPDATE through the CICS-DB2 attachment, or a JDBC client sends the same statement to DDF in DIST.
2. DB2 finds the package or prepares dynamic SQL, validates the authorization context, and selects the prepared access path.
3. DBM1 database services navigate the chosen index or table-space structures and fetch required pages into buffer pools when they are not already resident.
4. DB2 requests the required locks from IRLM. The thread proceeds immediately if compatible locks are available; otherwise it waits or eventually receives a timeout or deadlock result.
5. DB2 changes the buffered page and creates log records. The log makes the change recoverable before the altered data page is written to its table-space data set.
6. COMMIT makes the unit of work durable, ends or changes lock duration as appropriate, and returns success through the original allied attachment or DIST connection.

DB2 started tasks and subsystem startup

Operations teams use cataloged procedures to start the DB2 member and its dependencies. The exact command operands, procedure names, automation product, and sequencing belong to the installation. Conceptually, the matching IRLM must become available, DB2 system services initialize the member and logs, database services initialize shared database structures and buffer pools, and DDF becomes available according to configuration and commands. Automation often handles these dependencies, so copying a command from another site is unsafe.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Illustrative operations sketch only — names vary by installation:
 
  S DB2PIRLM                 Start the IRLM procedure for member DB2P
  S DB2PMSTR                 Start the DB2 subsystem procedure
 
Expected core job names after initialization:
  DB2PMSTR                   System services
  DB2PDBM1                   Database services
  DB2PDIST                   DDF, when configured and started
 
DB2 commands commonly used by operators:
  -DISPLAY DDF               Inspect distributed-service status
  -DISPLAY THREAD(*)         Inspect thread activity
  -DISPLAY LOG               Inspect log status
  -DISPLAY BUFFERPOOL(*)     Inspect buffer-pool status
 
These lines explain the model; use authorized site procedures in production.

Shutdown also requires coordination. A normal stop allows active work to reach controlled boundaries and gives DB2 an opportunity to quiesce services cleanly. More forceful modes exist for incidents, but they can increase restart work or disrupt applications. Operators monitor MSTR messages and confirm that DBM1, DIST, and the appropriate dependent spaces terminate as expected. IRLM shutdown is coordinated so that another DB2 member or dependent workload is not using it.

Diagnosing by address space without oversimplifying

Address-space knowledge gives troubleshooting a starting point, not a complete verdict. If remote clients cannot connect while local CICS transactions work, investigate DDF, DIST, TCP/IP, security, and connection limits first. If both local and remote work wait on the same object, inspect locking and the holder through IRLM-aware DB2 displays. If reads show heavy I/O suspension, investigate access paths and DBM1 buffer-pool behavior. If restart or log allocation messages appear, focus on MSTR and log infrastructure.

CPU attribution needs similar care. SQL that entered through DIST may drive database work associated with DBM1 and application enclaves. A WLM procedure can consume CPU in its own region while waiting on DB2 locks. An IRLM wait can be caused by poor application commit behavior rather than an IRLM defect. Follow the thread, correlation identifiers, accounting records, and wait reasons across components instead of blaming whichever job name first appears busy.

Practical operator questions

• Is the symptom local, distributed, or shared by both entry paths?
• Is work using CPU, waiting for I/O, waiting for a lock, or waiting for a connection?
• Which thread or unit of work owns the resource, and where did that thread originate?
• Are MSTR, DBM1, DIST, IRLM, and required WLM environments active and healthy?
• Did a recent subsystem, DDF, WLM, security, or application change alter the path?

Explain It Like I'm Five

Imagine a large library. MSTR is the head librarian who opens and closes the building, keeps the official event journal, and organizes emergencies. DBM1 is the main reading room where books are brought to desks and pages are used; its desk shelves are like buffer pools. IRLM is the sign-out clerk who prevents two people from changing the same book at once. DIST is the mail desk that accepts requests from people outside the building. A classic SPAS was one old workshop for special jobs. WLM provides several modern workshops and decides how many workers each kind of special job should receive. A visitor may enter through the front door or mail desk, but all the workers cooperate to find the book, protect it, record changes, and return an answer.

Exercises

1. For an SSID of D91A, write the likely job names for MSTR, DBM1, and DIST. Then explain why you still need the site runbook before issuing a z/OS START command.
2. Draw the path of a local CICS UPDATE and label where attachment, buffered page access, locking, logging, and COMMIT coordination occur.
3. Extend the drawing for a JDBC SELECT. Identify what DIST adds and which services remain shared with the local path.
4. A JDBC application cannot connect, but local batch SQL succeeds. List four checks that focus on DDF without assuming DBM1 is down.
5. An application receives a deadlock. Explain why the presence of IRLM in the error path does not necessarily mean IRLM is faulty.
6. Compare classic SPAS with two WLM application environments: one for short online procedures and another for resource-heavy batch procedures. Describe the isolation and workload-management advantages.
7. In SDSF, locate the address spaces for a test subsystem and classify each as system services, database services, distributed services, lock management, or WLM routine execution. Do not issue commands unless authorized.
8. Explain why an UPDATE can be committed before its changed table-space page is written to disk, and identify the DB2 logging rule that makes this safe.