What is a Db2 subsystem?

Db2 subsystem basics

A Db2 subsystem is a distinct running instance of Db2 for z/OS. Operators start and stop it; applications attach to it; its subsystem ID (SSID) appears in messages, connection settings, and many operational commands. A single LPAR can host more than one Db2 subsystem (for example separate test and production), though production designs vary by shop standards.

Starting Db2 brings up cooperating address spaces—commonly described as system services, database services, distributed data facility (DDF), and others—plus a partner IRLM for locking. Together they accept SQL from batch, TSO, CICS, IMS, and remote clients, manage buffers and logs, and protect integrity. You will study those address spaces in dedicated pages; here the point is that “the subsystem” is a team of address spaces, not a solitary task.

1
2
3
4
5
6
7
8
9
10
11
Examples of SSID naming (shop conventions vary)
-----------------------------------------------
DB1P   Production subsystem
DB1T   Test subsystem
DSN1   Default-style lab name
 
Attachment sketch
-----------------
COBOL batch  --attach-->  SSID DB1P
CICS         --attach-->  SSID DB1P
Remote app   --DDF------>  location name (group or subsystem)

Subsystem versus “database”

Beginners who know Db2 LUW sometimes call the whole server “the database.” On z/OS, a database is a logical container inside the subsystem (see the databases page). One subsystem hosts many databases—user databases, the catalog DSNDB06, the directory DSNDB01, work files, and more. Saying “the Db2 subsystem is down” means the instance is unavailable; saying “database PAYROLL is stopped” means a subset of objects is unavailable while the subsystem may still be up.

Db2 members

When a subsystem participates in data sharing, that subsystem is called a member of the data sharing group. Member is therefore a role name for a subsystem in a sharing configuration—not a different product. People say “member DB1A failed over” meaning that subsystem’s workload needs to run elsewhere in the group.

Each member can belong to one and only one data sharing group. All members of a group must reside in the same Parallel Sysplex. Non-data-sharing subsystems still exist and are common in smaller or isolated environments; they simply are not called members of a group because no group is defined.

Db2 data sharing groups

A data sharing group is a collection of one or more Db2 subsystems that share Db2 data. IBM’s purpose statement is practical: applications that reside on multiple Db2 subsystems in a Parallel Sysplex can read from and write to the same Db2 for z/OS data concurrently, with integrity, performance, scalability, and dynamic workload balancing.

All members of a group share the same catalog and directory. User data that members access together must reside on shared disks. The documented maximum is 32 members. Distributed applications often connect using a group location name, receiving a single-system image while Sysplex routing spreads work across available members.

Why coupling facilities matter (awareness level)

Data sharing relies on Parallel Sysplex infrastructure, including coupling facility structures for global locking and group buffer pools (plus other structures such as the shared communications area). You do not configure those as an application developer, but you should know that “two subsystems on two LPARs” is not enough by itself—the Sysplex plumbing must be present for true data sharing with concurrent update integrity.

Benefits beginners should remember

• Availability — take a member down for maintenance; others continue serving shared data
• Scale-out — add members and processor capacity horizontally
• Workload balance — route work across members
• Single image for many clients — connect to the group location name

1
2
3
4
5
6
7
8
9
10
11
12
Non-data-sharing
----------------
LPAR1: Subsystem DB1P  --> its catalog, data, logs, work files
 
Data sharing (sketch)
---------------------
Sysplex
  Member DB1A (LPAR1) \
  Member DB1B (LPAR2)  }--> shared catalog/directory + shared user data
  Member DB1C (LPAR3) /     each member: own logs, local pools, work files
         |
         +--> Coupling Facility structures (locks, GBP, ...)

How this affects your daily work

Application programmers still write SQL against tables. The subsystem or group you attach to determines which copy of the world you see. In data sharing, commits on member A are visible to member B because they share the data—locking and caching protocols keep that safe. In non-data-sharing, two subsystems mean two separate Db2 worlds unless you deliberately copy or distribute data.

Operators care about SSID when starting, stopping, and displaying Db2. Capacity planners care about per-member resources (CPU, local pools, work files) even when data is shared. DBAs care that DDL against the shared catalog affects the whole group. When someone says “recycle Db2,” clarify whether they mean one member or an action with group-wide impact.

Explain It Like I'm Five

A subsystem is like one kitchen in a restaurant, with its own cooks (address spaces) and its own ticket rail (SSID). A data sharing group is several kitchens in the same hotel that share one giant pantry and one recipe book (shared data, shared catalog). Each kitchen is a member. They keep their own notepads and trash cans (logs and work files), but they cook from the same ingredients so guests get the same food no matter which kitchen prepares the order. Special hotel radios (coupling facility) stop two kitchens from grabbing the same steak at once.

Exercises

1. Define subsystem, member, and data sharing group in one sentence each without reusing the same verb.
2. List three resources that are shared in a group and three that stay local per member.
3. Why might a shop run two non-sharing subsystems on one LPAR instead of data sharing?
4. What goes wrong conceptually if two subsystems update the “same” tables but do not share catalog/directory/disks as a group?
5. Explain why work file shortages can be member-local even when user data is shared.