Deleting data sharing members with missing BSDS data sets

The usual process for delete data sharing members requires that the bootstrap data sets (BSDSs) for all members exist. However, sometimes members cannot start because their BSDSs are missing.

Before you begin

Use this process with caution, and use it only for members that are missing BSDS data sets.

Important: Always make a backup copy of existing BSDSs for each member in the group before proceeding, and keep documentation in case you need to contact IBM Support later.

If some members to be destroyed have BSDS data sets, use this process for the members with missing BSDS data sets first. Then, use the normal process for deleting the members that still have BSDSs. See Deleting data sharing members.

For the purposes of this task, any member that still has a BSDS that will be destroyed later is also considered a surviving member.

Procedure

To delete members from a data sharing group that cannot be deleted with the usual process because of missing BSDS data sets, complete the following steps:

Quiesce the data sharing member with missing BSDS by completing the following steps:
1. Obtain the current group status by issuing the following commands:
```
D XCF,GROUP,groupname,ALL
```
```
-DIS GROUP
```
2. Stop all Db2 data sharing members.
3. Destroy the SCA structure, which forces Db2 to rebuild it from a member BSDS by issuing the following command, where strname is name of the SCA structure.
```
SETXCF FORCE,STRUCTURE,STRNAME=strname
```
4. Start one of the surviving members in maintenance mode by specifying the ACCESS(MAINT) option.
  Db2 issues messages DSNR020I and DSNR030I for each member with a missing BSDS.
5. When Db2 issues message DSNR020I for each member, reply 'QUIESCED'.
6. When Db2 issues message DSNR030I for each member, reply 'YES'.
7. Start the remaining surviving members in maintenance mode to update their BSDSs to indicate that the member to be deleted is quiesced.
8. Stop all data sharing members.
  
  Important: Do not restart any members until you complete all steps that precede step 3.e.
Deactivate the data sharing member.
1. Use the DSNJU004 utility to ensure that the BSDSs of all surviving members of the group indicate that the member that is to be deactivated is in the quiesced state.
2. Make a backup copy of all the BSDSs in the group.
3. Use the following utility control statement against all BSDSs of all surviving members of the group. x is the member ID of the member that is to be deactivated.
```
DSNJU003 DELMBR DEACTIV,MEMBERID=x
```
Destroy the data sharing members by completing the following steps:
1. Make a backup copy of all the BSDSs in the group.
2. Use the following utility control statement against the BSDS of each surviving member of the group. x is the member ID of the member that is to be destroyed.
```
DSNJU003 DELMBR DESTROY,MEMBERID=x
```
3. Use the DSNJU004 utility to ensure that the member to be destroyed is marked for destruction in the BSDS for every surviving member.
4. Check that all members in the data sharing group have QUIESCED state by issuing the following command.
```
D XCF,GROUP,groupname,ALL 
```
5. Start a surviving member with maintenance access by specifying the ACCESS(MAINT) option. The open of the BSDS fails for the member that is to be destroyed, with the following messages:
  - DSNJ103I LOG ALLOCATION ERROR
  - DSNJPB01 ERROR ATTEMPTING TO ACCESS BSDS FOR PEER MEMBER
  However, Db2 determines from the SCA that the member is quiesced, so the -START DB2 command succeeds. The member is destroyed, and Db2 issues the following message: DSNR063I DSNRRGRT MEMBER SUCCESSFULLY DESTROYED.
6. Start the surviving members with the ACCESS(MAINT) option.
7. Issue the following commands and verify that the output lists only the surviving members:
```
-DIS GROUP
```
```
D XCF,GROUP,groupname,ALL
```
8. Stop all surviving members and restart normally.