Online utility jobs in data sharing environments

If you specify a group attachment name, you can also specify a subgroup attachment name. When you submit a utility job, you must specify either the group attachment name or the name of the member to which the utility is to attach.

For example, if you specify the group attachment name, the EXEC statement might look like the following statement:

//stepname EXEC PGM=DSNUTILB,PARM='group-attach-name,[uid],[utproc]'

If you do not use the group attachment name, the utility job must run on the z/OS® system where the specified Db2 subsystem is running. Ensure that the utility job runs on the appropriate z/OS system. You must use one of several z/OS installation-specific statements to make sure this happens. These include:

For JES2 multi-access spool (MAS) systems, insert the following statement into the utility JCL:
```
/*JOBPARM SYSAFF=cccc
```
where cccc is the JES2 name. You can specify an asterisk (SYSAFF=*) to indicate that the job should run on the system from which it was submitted.
For JES3 systems, insert the following statement into the utility JCL:
```
//*MAIN SYSTEM=(main-name)
```
where main-name is the JES3 name.

Your installation might have other mechanisms for controlling where batch jobs run, such as the use of job classes.

How to stop and restart utilities

In a data sharing environment, you can use the TERM UTILITY command to stop the execution of an active utility only from the member on which the utility is active. You can then use this same command from any active member of the data sharing group to release the resources that are associated with the stopped utility. If a member fails while a utility is executing, you must restart Db2 on either the same or another z/OS system before stopping the utility. For remote site recovery from a disaster at the local site, you can stop utilities that were active at the local site from any restarted member of the group at the remote site.

Recommendation: Define all work data sets that are used by utilities on shared disks. Doing so allows you to restart a utility on any member because all members are able to access all required data sets. Use the same utility ID (UID) to restart the utility. UIDs are unique within a data sharing group. If a member fails while a utility is executing, you must restart Db2 on either the same or another z/OS system before restarting the utility.

How to alter a REORG job

In a data sharing environment, you can use the ALTER UTILITY command to alter the REORG utility only from the member on which the utility is active. This is true for non-data sharing environments as well.