Configure DB2 data sharing

What configuration means

A data sharing group is a named set of Db2 members that share the Db2 catalog and directory and reside in the same Parallel Sysplex. Each member is a full Db2 subsystem with its own address spaces, logs, and BSDS, but they coordinate through the coupling facility: the shared communications area (SCA), lock structure, and group buffer pools (GBPs).

You normally enable data sharing on an existing subsystem that becomes the originating member. Additional members are installed into the group and use the originating catalog. Merging data from independent subsystems into one group catalog is a separate migration design problem—Db2 does not auto-merge catalogs.

Prerequisites

Confirm Parallel Sysplex health, coupling facility capacity and policies, XCF connectivity, shared DASD access for the catalog, directory, and user data you intend to share, and a naming convention that is unique across the Sysplex. Plan the group name, member names, group attachment name, command prefixes, IRLM group name, and structure names before you change production definitions.

You need installation authority, time windows for IPLs or SETSSI changes when IEFSSNxx definitions change, CFRM policy updates for SCA, lock, and GBP structures, and a rollback plan. Read the current Db2 Data Sharing: Planning and Administration guide for your release; structure sizes and enablement jobs are release-sensitive.

• Healthy Parallel Sysplex and CF capacity
• Approved naming standard for group and members
• Shared access to catalog, directory, and shared data
• CFRM policy updates prepared
• Change window and verification checklist

Steps: plan and enable the originating member

Document the group attachment name and member-specific subsystem names. Run the installation and migration jobs your site uses to enable data sharing on the originating member (commonly including jobs such as DSNTIJMV to redefine the subsystem to z/OS and IRLM). Update SYS1.PARMLIB IEFSSNxx if the command prefix or group attachment name changes, then IPL or apply SETSSI changes per site procedure.

Define and allocate coupling facility structures for the SCA, lock structure, and group buffer pools that match your buffer pool design. GBP page sizes must align with the local buffer pools that cache shared objects. Start Db2 on the originating member and confirm it joins the group cleanly before adding more members.

1
2
3
4
5
* Example concepts (names are site-specific):
* Group name / group attachment: DB0A
* Member SSIDs: DB2A, DB2B
* Command prefixes unique per member or scoped as designed
* CF structures: SCA, LOCK1, GBP0, GBP1, ...

Steps: add members and operational settings

Install each additional member as a new Db2 into the existing group so it uses the shared catalog. Align ZPARM choices that must be consistent across members, keep member-unique values where required (logs, BSDS, work files), and ensure applications can use the group attachment name for failover-friendly connections.

Configure GBP duplexing, recovery, and monitoring according to availability goals. Train operators on member START/STOP, QUIESCE behavior, and the difference between member-scope and group-scope commands. Quiesced members still appear in DISPLAY GROUP with QUIESCED status.

Verify results

Issue -DISPLAY GROUP and -DISPLAY GROUP DETAIL from each member. Confirm the group name, member names, statuses (ACTIVE expected for running members), catalog level, and function level. Verify GBP status with -DISPLAY GROUPBUFFERPOOL and local pools with -DISPLAY BUFFERPOOL. Run a controlled shared-table update from two members and confirm both see committed data.

Validate locking and recovery expectations in a test window: force a member outage and confirm surviving members continue work on shared data. Check SMF and console messages for structure rebuild or connector failures. Only then point production attach names at the group.

1
2
3
4
-DISPLAY GROUP
-DISPLAY GROUP DETAIL
-DISPLAY GROUPBUFFERPOOL(*)
-DISPLAY BUFFERPOOL(*)

Common errors

Enablement often fails because names collide in the Sysplex, CF structures are missing or undersized, shared DASD access is incomplete, IEFSSNxx was not activated, or IRLM group definitions disagree. Members that cannot connect to the SCA or lock structure will not join cleanly.

Runtime problems include GBP shortages, false contention, inconsistent ZPARMs, applications still pointing at a single member SSID instead of the group attach name, and misunderstanding QUIESCED versus failed members. Use DISPLAY GROUP, DISPLAY GROUPBUFFERPOOL, and coupling facility monitors before changing application routing.