Renaming the originating Db2 subsystem for a new data sharing group

When you enable Db2 data sharing, you can rename the Db2 subsystem that becomes the originating member and reuse the original subsystem name as the group attach name. The result is that existing jobs and other workloads can continue to connect to the group instead of the subsystem, without modifications to the jobs or applications.

Before you begin

Renaming a Db2 subsystem and renaming members in a data sharing group require careful planning. Also, because every installation has a different configuration, this procedure might not be complete for your environment.

Tip: Rename the originating subsystem during the process for enabling Db2 data sharing because Db2 must be stopped when you complete this process.

About this task

The following procedure describes an approach to changing the name of the Db2 subsystem that becomes the originating member of a new data sharing group. It is a variation of the process for enabling data sharing, as described in Enabling Db2 data sharing.

The examples change the name of member DB2P to DB1A, which conforms to the naming convention used in other examples in the Db2 data sharing information

Procedure

To rename the originating member when enabling data sharing, complete the following steps:

  1. Define the correct profile names for the DSNR class. Make sure that RACF definitions are in place to handle the new subsystem names. Add the correct names to the following tables:
  2. Replicate existing PERMIT commands to allow users and groups to access the new profiles.
  3. Run the installation CLIST, as described in Running the CLIST for enabling data sharing, and update the following values (you cannot change the subsystem name on the installation panels):
    1. On installation panel DSNTIPH, modify the archive prefix names to include the member name; for example: DB2PCAT.DB1A.ARCLG1
    2. Specify the old subsystem name (for example: DB2P) as the group attachment name.
  4. Modify the IEFSSNxx member for this subsystem to include the group attachment name.
    Tip: To avoid having to modify JCL for all your jobs, use the existing subsystem name as the group attachment name.
    This step is necessary to ensure that there are no problems when the call attachment and TSO attachment facilities try to use the group attachment name.
    For example, if the existing IEFSSNxx member looks like this:
    DB2P,DSN3INI,'DSN3EPX,?'
    Change it to look like this:
    DB2P,DSN3INI,'DSN3EPX,?,S,DB2P'
  5. Add new IEFSSNxx definitions for the new name and prefix by taking one of the following actions:
    • Modify the names to the IEFSSNxx member and IPL z/OS. For example:
      DB1A,DSN3INI,'DSN3EPX,-DB1A,S,DB2P'

      The command prefix -DB1A is not a subset or a superset of the DB2P command prefix. For example, ?DB1A is not valid in this context.

    • Use the z/OS command SETSSI to set the definitions without an IPL. For example:
      SETSSI ADD,SUBNAME=DB1A,INITRTN=DSN3INI,INITPARM='DSN3EPX,-DB1A,S,DB2P'

      If you use this alternative, you must also add the new name and prefix to the IEFSSNxx member before the next IPL.

    You can leave the old IEFSSNxx definitions in place until you complete the process of enabling data sharing. However, it is best to remove them after you finish enabling data sharing. The change does not take effect until the next IPL of z/OS. However, you can use an SETSSI command to delete the obsolete definition until the next IPL, for example:
    SETSSI DELETE,SUBNAME=DB2P,FORCE
  6. Stop Db2 and ensure that all work is stopped:
    1. Issue a STOP DB2 command with the MODE(QUIESCE) option.
    2. Restart Db2 in ACCESS(MAINT) mode.
    3. Issue a -DISPLAY THREAD(*) TYPE(*) command to identify indoubt threads. Then use the -RECOVER INDOUBT command for any indoubt threads.
    4. Issue a -DISPLAY UTILITY(*) command to identify unterminated utilities. Then use the -DSN1 TERM UTILITY(*) command to terminate all utilities.
    5. Stop Db2 with the MODE(QUIESCE) option.
  7. Rename the BSDS and active log data sets with the new prefix, like DB2PCAT.DB1A.BSDS01.
  8. Modify and run job DSNTIJIN to alter the active log data sets to specify SHAREOPTIONS(2 3). Before running the job, verify that the AMS ALTER statements there specify the new name for the active log data sets.
  9. Update the BSDS with the renamed log data sets. Include the same RBA ranges as the original active log data sets:
    1. Run the utility print log map (DSNJU004) to obtain the start and end RBAs.
    2. Run the utility change log inventory (DSNJU003) to delete the active logs with the old names.
    3. Run the utility change log inventory (DSNJU003) to add the renamed active logs with the correct ranges. You do not need to add the archive log data sets. The archive log data sets that you specified on panel DSNTIPH replace them.
  10. If necessary, increase the size of the BSDS.
  11. Run the following jobs to define system settings.
    1. Run job DSNTIJUZ to assemble and link-edit the new subsystem parameter (DSNZPxxx) module. First, verify these settings:
      • DSN6GRP.MEMBNAME: The member name; for example: DB1A
      • DSN6ARVP.ARCPFX1 and DSN6ARVP.ARCPFX2; for example: The archive log data set name prefixes; for example: DB2PCAT.DB1A.ARCHLOG1
      • DSN6SPRM.ADMTPROC: The name of the Db2 Administrative Scheduler address space procedure; for example: DB1AADMT
    2. Run job DSNTIJUA to assemble and link-edit the new application programming default (DSNHDECP) module. First, verify the setting of the DSNHDECM.SSID parameter for the group attach name; for example: DB2P
    3. Run job DSNTIJUL to modify the BSDS and establish the subsystem as the first member of the group. Before running the job, verify the following settings:
      • The names of the BSDS; for example: DB2PCAT.DB1A.BSDS01
      • The GROUPMEM parameter; for example: GROUPMEM=DB1A
  12. If necessary, increase the size of the SYSLGRNX table space.
  13. Rename the startup procedures. For example, change DB2PMSTR to DB1AMSTR. Do not forget to change the BSDS names to the new names in the ssnmMSTR startup procedure.
  14. Modify the IRLM startup procedure for the member.
    1. Change the SCOPE parameter setting from LOCAL to GLOBAL.
    2. Set the IRLMGRP parameter to the name that is to be used for the IRLM group. This name must be different from the Db2 group name.
  15. Verify that CICS can connect to the new Db2 subsystem. There are several ways of doing this, depending on which level of CICS you are running.
    For example, you might use one of the following techniques:
    • Change the CICS DB2CONN to use the new Db2 subsystem name, reassemble, and link-edit.
    • Modify the JCL for CICS to include the new subsystem name on the INITPARM.
  16. Verify that IMS can connect to the new Db2 subsystem.
  17. Start Db2 by issuing a START DB2 command.

What to do next

Complete the process for enabling data sharing, by continuing with the step described in Creating the default storage group and defining temporary work files: DSNTIJTM.

After data sharing is enabled, remove old definitions from the IEFSSNxx member, as described at the end of step 5.