Group attachment names and subgroup attachment names

Group and subgroup attachments are used by TSO, CAF, RRSAF, JDBC, ODBC, and Db2 utilities connections to find active Db2 subsystems.

A group attachment name acts as a generic name for all the members of a data sharing group. Subgroup attachment names can be used to specify a subset of members within a group attachment and provide more organization and control over connection requests. To specify subgroup attachment names, you must use Db2 12 early code.

Specify the group attachment name and subgroup attachment name for a subsystem in member IEFSSNxx. You can let the Db2 installation process do this for you by specifying the names on installation panel DSNTIPK, or you can update the member yourself. If you use the DSNTIPK panel, the installation CLIST places the specified names in the IEFSSNxx member and in the DSNHDECP load module for the group. Specify the group attachment name and subgroup attachment name at a convenient time (during a planned IPL, for example).

The following rules apply to group attachment and subgroup attachment names:

  • A subgroup attachment cannot have the same name as a group attachment.
  • Neither the group attachment nor the subgroup attachment should have the same name as a Db2 member.
  • If you specify a subgroup attachment name, you must also specify a group attachment name. A subgroup attachment must belong to one, and only one group attachment.
  • A member can belong to one subgroup attachment at most and does not need to belong to a subgroup attachment.

The group attachment name and subgroup attachment name are included in the output for the command DISPLAY GROUP.

Even if you have not yet enabled data sharing, the group attachment name and subgroup attachment name is active after you IPL the system. An active group attachment name and subgroup attachment name in a non-data sharing environment is not a problem. Until you are ready to move to data sharing, continue to specify the Db2 subsystem name in your TSO and batch jobs. When you are ready to move to data sharing, you can change those jobs to specify a group attachment name and subgroup attachment name without the need for an IPL.

How Db2 chooses a subsystem name

When you submit a job on a z/OS® system, Db2 treats the name that you specified on the Db2 connection request as a subsystem name, a group attachment name, or a subgroup attachment name. Db2 first assumes that the name is a subsystem name and attaches to that subsystem if either of the following is true:
  • The subsystem is started.
  • The subsystem is not started, and NOGROUP was specified in the Db2 connection request. NOGROUP indicates that group attachment or subgroup attachment processing is not to be considered. If RETRY was specified in the command, Db2 tries to attach the subsystem again in 30 seconds. The value of RETRY determines the number of times that Db2 re-attempts to attach.
Db2 assumes that the name on the Db2 connection request is a group attachment name or subgroup attachment name if no qualifying subsystem is found and either of the following is true:
  • No subsystem with the name in the command is defined.
  • A subsystem with that name is not started, the group attachment name or subgroup attachment name is the same as its subsystem name, and NOGROUP was not specified in the Db2 connection request.

When Db2 assumes that the name is a group attachment name or subgroup attachment name, it performs the following actions:

  • Constructs a list of Db2 subsystems that are defined to this z/OS.

    To create the list, Db2 adds each subsystem during subsystem initialization. At IPL time, subsystems are initialized in the order in which they appear in member IEFSSNxx if the MVS™ Subsystem Interface (SSI) is running on a single processor. If the MVS SSI is running on multiple processors in parallel, the subsystems are placed in the group attachment name list in the order that they complete initialization. In this case, the order of the list is unpredictable. If you add a subsystem with the z/OS SETSSI command, that subsystem is added to the list at that time.

  • Tries to attach to the subsystems in the list in random order until it finds one that is started on this z/OS. However, if RANDOMATT=NO has been specified for a Db2 subsystem, that subsystem is excluded from the random search.
  • Searches for any available Db2 subsystem within the group or subgroup, including those that specify RANDOMATT=NO, if the random search finds no available Db2 subsystems or if RANDOMATT=NO is specified for all subsystems. Search order is defined according to the order in which z/OS subsystem initialization completes for each Db2 subsystem. If you want to direct work to certain Db2 subsystems, set the RANDOMATT subsystem parameter to YES on those subsystems. If you want to direct work away from certain Db2 subsystems, set the RANDOMATT subsystem parameter to NO on those subsystems.

If the name on the Db2 connection request is not a group attachment name or subgroup attachment name, a not started message is returned.

If you need to prevent a batch workload from running on a Db2 subsystem that is intended for high-performance online transactions, specify RANDOMATT=NO for the online subsystems and RANDOMATT=YES for the batch workload subsystems. In that case, the batch jobs use the group attachment name or subgroup attachment name, and the online subsystem does not.

Alternatively, to achieve non-randomized group attachments or subgroup attachments, as in Version 8 of Db2, specify RANDOMATT=NO for all members of the group.

When a subsystem and a group attachment name or subgroup attachment name are the same

When you begin moving to data sharing, ensure that your IEFSSNxx definitions are correct and Db2 connection requests are coded to get the results that you intend. You should especially ensure that the definitions are correct when the group attachment name or subgroup attachment name is the same as a subsystem name. Incorrect IEFSSNxx definitions might be troublesome if you have inactive subsystems that are still defined but not used.

Assume you have the following subsystem definitions on a z/OS system: 
DB2A,DSN3INI,'DSN3EPX,-DB2A,S'  ←Inactive subsystem
DB1A,DSN3INI,'DSN3EPX,-DB1A,S,DB2A'  ←Active subsystem
The jobs that are submitted on this z/OS system try to connect to the name DB2A. Db2 tries to connect to subsystem DB2A before considering group attachment processing. However, because DB2A is not started and it lacks a group attachment name, Db2 does not invoke group attachment processing and find DB1A as you might have intended. To avoid this situation, include the group attachment name in the definition of DB2A, or remove entry IEFSSNxx for subsystem DB2A if it is obsolete. With DB2A defined as the group attachment name for subsystem DB2A, Db2 tries to attach to DB1A after it discovers that DB2A is not started.

Alternatively, you might want a job to connect to a specific subsystem, but it connects to another subsystem in the group instead.

Assume that you have the following subsystem definitions on a z/OS system: 
DB1A,DSN3INI,'DSN3EPX,-DB1A,S,DB1A'.  ←Inactive subsystem
DB2A,DSN3INI,'DSN3EPX,-DB2A,S,DB1A'.  ←Inactive subsystem
DB3A,DSN3INI,'DSN3EPX,-DB3A,S,DB1A'.  ←Active subsystem

Notice that DB1A is specified as a subsystem and also as the group attachment name for all three subsystems.

The jobs are submitted on this system with a Db2 connection request that specifies the name DB1A and omits the NOGROUP keyword. Db2 tries to connect to subsystem DB1A, but does not. Instead, Db2 invokes group attachment processing and eventually connects to DB3A, the first active subsystem with the group attachment name. You might have intended that the job connect only to DB1A. To ensure that Db2 connects to subsystem DB1A and no other subsystem, specify NOGROUP in the Db2 connection request to disable group attachment processing. Specify the RETRY keyword in the request to indicate the number of times, at 30-second intervals, that Db2 will try to connect to DB1A again.