Disabling data sharing

You should only disable data sharing with caution and with a thorough understanding of the process and results. Very few situations create a need to disable Db2 data sharing, such as if you have data sharing problems and one-way data sharing does not work.

Before you begin

All page sets must be converted to extended format. For details, see What to do before RBA or LRSN limits are reached.

About this task

The procedure to disable data sharing ensures that the most recent versions of all pages are externalized from the group buffer pool to disk. Db2 does not use the group buffer pool after data sharing is disabled. You must ensure that data is written to disk, or else you lose data when you start Db2 after disabling data sharing.

Important: Other members' logs are not available to the surviving member after you disable data sharing.

You must also ensure that there is no need to recover data from information that is contained in other members' logs after you disable data sharing. To prevent the surviving member from applying inconsistent updates during recovery processing, a cold start is required to disable data sharing.

Important: Do not attempt to go through the installation process to re-enable data sharing after you have disabled it.

Procedure

To disable data sharing and return to a non-data-sharing environment:

Decide which member will be the surviving member of the group. The surviving member is the only member that can access previously shared data.
Stop all members by entering the following command for each member of the data sharing group:
```
STOP DB2 MODE(QUIESCE)
```
Start the surviving member in maintenance mode by using the following command:
```
START DB2 ACCESS(MAINT)
```
Make sure that data is consistent.
Enter the following commands from the surviving member of the group. Do not proceed to the next step until all problems are resolved.
- DISPLAY GROUP
  Ensure that the status of the surviving member is ACTIVE and that the status of all other members is QUIESCED. If the status of a non-surviving member is not QUIESCED, take the following actions, depending on the member's status:
  - If the member's status is FAILED, restart and then stop the member.
  - If the member has castout problems, indoubt units of recovery, or outstanding resynchronization problems, start that member in maintenance mode and fix the problem.
- DISPLAY UTILITY(*)
  If any utility work remains for any member of the group, restart that member with ACCESS(MAINT) and either stop the utility or let it finish.
- DISPLAY DATABASE(*) SPACENAM(*) RESTRICT
  If any restricted table spaces or index spaces (such as write error ranges, recovery pending status, or logical page list entries) exist, recover them from the surviving member.
Stop the surviving member by using the following command:
```
STOP DB2 MODE(QUIESCE)
```
Stop any IRLMs that have not stopped by using the following command:
```
STOP irlmproc
```
Dismantle the data sharing group.
1. Enter the following command to display the structures for the data sharing group:
```
D XCF,STRUCTURE,STRNAME=grpname*
```
2. For all structures that are still allocated (STATUS:ALLOCATED) and that still have connections (which appear as FAILED PERSISTENT), enter the following command to force the connections off of those structures:
```
SETXCF FORCE,CONNECTION,STRNAME=strname,CONNAME=ALL
```
  Important: If your site is running z/OS® with APAR OA02620 applied, you do not need to force failed-persistent connections off of the lock structure. When you forcibly deallocate the lock structure (see the next step), the system deletes failed-persistent connections to the structure for you.
3. Delete all the Db2 coupling facility structures by using the following command for each structure:
```
SETXCF FORCE,STRUCTURE,STRNAME=strname
```
4. Edit the JCL in job DSNTIJGF to point to the correct BSDS data sets.
  DSNTIJGF is a change log inventory job that sets up the surviving member for a cold start.
  
  Important: Do not change the hex values that appear in the change log inventory CRESTART control statement. They are not real RBA values.
5. Run job DSNTIJGF.
  After you run this job, do not try to restart any of the non-surviving members. None of those members can start successfully.
Change the IRLM procedure to SCOPE=LOCAL.
Start the surviving member with ACCESS(MAINT).
Specify the old DSNZPxxx from the non-data sharing environment, where the DSHARE subsystem parameter is set to NO. If you do not have the old DSNZPxxx or if the surviving member is not the originating member, reassemble the surviving member's subsystem parameters with DSHARE=NO in the invocation of the DSN6GRP macro. Also, comment out all steps from the DSNTIJUZ job except for those that reassemble and link-edit the subsystem parameters.
When you start Db2 after running DSNTIJGF, respond with Y to a cold start prompt (message DSNJ246I on the z/OS console).

This is a cold start because Db2 increases the log RBA to a value higher than any LRSN used while sharing data. From this point on, your RBAs look like LRSNs.
Edit and run job DSNTIJFT, if necessary, to ensure that the surviving member's work file database is DSNDB07.
The surviving member must use DSNDB07 as its work file database. If the work file database for the surviving member is not DSNDB07, drop that work file database and run job DSNTIJFT.
Verify that the surviving member works by running a subset of the Db2 13 installation verification sample jobs.
To establish a new recovery point, take a full or incremental image copy or non-Db2 backup of all data.
Run job DSNTIJIC to image copy the Db2 catalog and directory.
Recommendation: Perform this step as soon as possible after data sharing is disabled.
Stop and restart Db2 for normal unrestricted access.

What to do next

After disabling Db2 data sharing, you can continue to use the group attachment name or subgroup attachment name. The group attachment name or subgroup attachment name does not need to be changed to the surviving member's subsystem ID.