Db2 Address Spaces Overview

Why address spaces matter

On z/OS, work runs inside address spaces (sometimes called regions). Isolation matters: virtual storage, dispatching priority, and failure domains can differ by address space. Db2 uses that model deliberately. Instead of putting logging, buffer pools, network listeners, and lock management into one giant process, Db2 splits responsibilities so the subsystem can scale, recover, and be monitored more clearly.

For beginners, the practical payoff is reading SDSF, messages, and monitoring tools. When CPU spikes in DBM1, you think about buffer pools, prefetch, or data access. When DIST is busy, you think about remote DRDA traffic. When IRLM shows contention, you think about locks and concurrency. Knowing the map turns mysterious job names into a story.

Naming usually follows the subsystem ID. If your SSID is DB2P, you often see names like DB2PMSTR, DB2PDBM1, and DB2PDIST. IRLM has its own procedure name configured for the site. Exact names vary—always confirm with your systems programmer.

1
2
3
4
5
6
7
8
9
Typical Db2 subsystem picture (names are examples):
 
  SSID = DB2P
    ├── DB2PMSTR   System services (ssnmMSTR)
    ├── DB2PDBM1   Database services (ssnmDBM1)
    ├── DB2PDIST   Distributed Data Facility / DDF (ssnmDIST)
    ├── DB2PIRLM   Internal Resource Lock Manager (IRLM)
    ├── WLM ASs    Stored procedures and UDFs (as defined)
    └── Allied     CICS, IMS, TSO, batch attachments issuing SQL

Quick reference: the main Db2 address spaces

System services address space (ssnmMSTR)

The system services address space—commonly called MSTR or SSAS in older materials—performs system-related control for the subsystem. IBM documentation describes it as the space that starts and stops Db2, controls local access aspects, and performs various system functions. Logging and related recovery-oriented system activity are closely associated with this address space.

Think of MSTR as the subsystem’s control tower. Application SQL does not “live” here the way buffer pools do, but without MSTR the coordinated subsystem cannot start, stop, or manage the system services that keep Db2 coherent. When you issue Db2 commands or watch startup messages, you are often interacting with work that involves system services.

What beginners should remember about MSTR

• Associated with subsystem start/stop and system control functions
• Closely tied to logging and commit/backout-related system processing
• Not where you usually picture table page buffers living (that is DBM1)
• Visible in SDSF as something like ssnmMSTR for your subsystem

Database services address space (ssnmDBM1)

The database services address space—DBM1—provides most database-related services. This is where buffer pools reside and where much of the work of accessing relational data on behalf of SQL programs occurs. Prefetch, space management, deferred write, and related data-path activity are classic DBM1 concerns.

Modern Db2 for z/OS makes heavy use of storage above the 2 GB bar in DBM1. With 64-bit addressing, buffer pools and thread-related storage can grow far beyond older virtual storage limits. That is one reason a single Db2 member can support large concurrent workloads when the LPAR and configuration are sized correctly.

What beginners should remember about DBM1

• Home of buffer pools and most database I/O on behalf of applications
• Central to SQL performance discussions (hits, prefetch, deferred writes)
• Often the largest “Db2 overhead” address space in CPU accounting studies
• Works with IRLM for locking and with MSTR for system coordination

Distributed Data Facility (DDF) and ssnmDIST

The Distributed Data Facility, often abbreviated DDF, runs in the ssnmDIST address space. DDF supports network communications with remote systems and executes database access requests on behalf of remote users. When a remote request arrives, DDF participates in receiving and coordinating it; the database I/O still involves DBM1.

If your shop has Java, .NET, or other mid-tier applications connecting with JDBC/ODBC over TCP/IP using DRDA, those connections depend on DDF. Local CICS or batch COBOL on the same LPAR typically uses attachment facilities rather than DDF, though architecture choices vary. Beginners should separate “local attachment” from “remote DDF client” even though both end up running SQL against the same tables.

1
2
3
4
5
Local path (conceptual):
  CICS / batch / TSO  --attachment-->  Db2 (MSTR/DBM1/IRLM)
 
Remote path (conceptual):
  Mid-tier app  --TCP/IP DRDA-->  DIST (DDF)  -->  DBM1 data services

IRLM — Internal Resource Lock Manager

IRLM is the lock manager Db2 uses to control concurrent access to database resources. Without locking, two transactions could update the same row and leave inconsistent results. IRLM tracks lock requests, helps detect deadlocks, and—especially in data sharing—participates in global lock coordination.

IRLM runs in its own address space (procedure name configured per site, often related to the subsystem). Operators usually start IRLM as part of bringing Db2 up, because locking must be available for safe multi-user access. In quiet systems, IRLM CPU is often lower than DBM1 or MSTR, but lock contention still shows up as application waits.

IRLM values to know

• Local locking: serializes access within a single Db2 subsystem/member
• Deadlock detection: finds circular wait conditions so Db2 can roll back a victim
• Data sharing: cooperates with coupling facility structures for global interest and lock state across members

Allied address spaces

Allied address spaces are the environments where applications attach to Db2 and issue SQL. They are allies of the Db2 subsystem rather than core Db2 engine spaces. Common allies include:

• CICS: online transactions using the CICS-Db2 attachment
• IMS: IMS applications attached to Db2
• TSO: interactive or batch TSO users and tools
• Batch: JCL job steps running COBOL or other languages with embedded SQL
• Other servers: environments such as WebSphere or utilities as configured at your site

From an application programmer’s view, you write EXEC SQL in COBOL and check SQLCODE. From an architecture view, your program’s address space is allied: it requests Db2 services, and Db2 performs database work largely in DBM1 while IRLM manages locks and MSTR handles system services. Understanding that split helps when someone asks whether a problem is “in CICS,” “in the batch job,” or “inside Db2.”

Stored procedure address spaces and WLM environments

Stored procedures and user-defined functions need somewhere to run. Historically, Db2 offered a stored procedures address space model (often discussed as SPAS / ssnmSPAS). Modern best practice on z/OS is to run procedures and UDFs in WLM-managed address spaces.

Workload Manager (WLM) environments let you define which procedures run where, how many address spaces can start, and how work is prioritized. Isolation means a misbehaving procedure is less likely to disrupt unrelated work. Priority means online procedures can be favored over low-priority batch-style routines when the system is busy.

WLM environments — beginner checklist

• Procedures are associated with a WLM application environment
• z/OS can start zero to many address spaces for that environment as needed
• Environments can separate high-priority online work from heavy batch procedures
• DBAs and systems programmers configure NUMTCB and related options carefully

You may still hear “SPAS” in older runbooks. When you do, ask whether the site still uses a classic stored procedure address space or has moved fully to WLM environments. The conceptual need is the same: run procedural SQL/logic outside the pure engine path with controlled isolation.

How the pieces work together

Imagine a CICS transaction updates a customer balance, and a remote reporting tool reads the same table through DDF. Locally, the CICS allied address space issues SQL; Db2 uses DBM1 for data pages and IRLM for locks; MSTR participates in system services including logging-related work so the update can be recovered. Remotely, DIST accepts the DRDA request and coordinates with database services for the read. Same tables, different entry paths, shared locking and logging rules.

Utilities also fit the picture. Many Db2 utilities run as batch jobs or stored procedures. They are not “extra address spaces named UTILITY,” but they use Db2 resources and appear in monitoring alongside the core spaces. Knowing the core map first makes utility and performance topics easier later.

Operational tips for new Db2 learners

• Learn your site’s SSID and the corresponding MSTR/DBM1/DIST job names
• Confirm the IRLM procedure name used in production and test
• Ask whether DDF is active and which ports/locations remote clients use
• Ask which WLM environments host critical stored procedures
• When troubleshooting, classify the symptom: attachment (allied), data path (DBM1), locks (IRLM), remote (DIST), or system/log (MSTR)

Explain It Like I'm Five

Imagine a busy restaurant. The kitchen (DBM1) cooks the food—the real database work. The manager’s office (MSTR) opens and closes the restaurant and keeps the official logbook. The lock box (IRLM) makes sure two waiters do not grab the same plate at once. The delivery door (DIST/DDF) handles orders that come from phones outside the building. Waiters (allied address spaces like CICS or batch) take orders from customers. Special bakers in a separate room (WLM stored procedure spaces) make cakes without crowding the main kitchen. Together they are “the restaurant is open”—just like many address spaces together mean “Db2 is up.”

Exercises

1. List the four core spaces most sites discuss first (MSTR, DBM1, DIST, IRLM) and write one sentence describing each.
2. Your SSID is DB2T. Guess likely names for MSTR, DBM1, and DIST, then verify against your site’s naming standard.
3. A JDBC application on a mid-tier server cannot connect, but CICS transactions on the same LPAR work. Which address space would you investigate first, and why?
4. Explain in your own words why stored procedures often run in WLM environments instead of inside DBM1.
5. Draw a simple diagram showing an allied CICS region, DBM1, IRLM, and MSTR for a local update, and add DIST for a remote SELECT.