DB2 Address Spaces

On z/OS, every running program lives in an address space - its own private area of virtual storage. DB2 does not run as one program; it runs as a set of address spaces that work together. Knowing which address space does what helps you read job logs and understand error messages.

The four main DB2 address spaces

• DSNMSTR (system services) - The master address space. It starts and stops DB2, handles DB2 commands, manages logging and recovery, and talks to z/OS.
• DSNDBM1 (database services) - Does the real database work: SQL execution, buffer pool management, sorting, and access to tables and indexes. This is usually the biggest address space.
• DSNDIST (distributed data facility) - Handles remote access: DRDA requests from other systems and DDF connections over TCP/IP. It only runs if DDF is started.
• DSNIRLM (internal resource lock manager) - Manages locks and latches for the subsystem. In data sharing, an external IRLM can be used instead.

How they work together

• When DB2 starts, DSNMSTR comes up first and then starts DSNDBM1, DSNDIST and the IRLM in the correct order.
• Your application thread runs in its own address space (batch job, CICS region, TSO) and talks to DSNDBM1 through cross-memory services - the data never passes through slow files.
• DSNDBM1 asks DSNIRLM for locks before touching data, and asks DSNMSTR to write log records.
• If DSNDBM1 abends, the subsystem usually has to be restarted, because that is where the database work happens.

Reading address space names in messages

• DB2 messages and dumps always name the address space they came from, so you know where to look.
• An error in DSNMSTR is often a startup, logging or command problem. An error in DSNDBM1 is often a SQL, buffer pool or storage problem.
• On the z/OS console you will see these started tasks with names like DSN1MSTR, DSN1DBM1, DSN1DIST - the middle part is the SSID (here DSN1).