Rules for extend storage groups

The following rules apply to the use of extend storage groups:

򐂰 The storage group you specify as an extend storage group must be a pool storage group. To be effective it must have volumes below their high allocation threshold.

򐂰 Only the systems running z/OS V1R3 DFSMS will use extend storage groups during EOV extend processing. If the systems in your SMSplex are running a mixture of code levels the lower level systems ignore the specification of the extend storage group.

Chapter 2. SMS enhancements 21

򐂰 You can reference extend storage groups directly in your Automatic Class Selection (ACS) routines, so you can use extend storage groups for allocations other than data set extends.

򐂰 There can only be one extend storage group for any single pool storage group. If you specify multiple storage groups today for a particular allocation then the storage group selected by allocation must specify an extend storage group for the use of the extend storage group to be successful.

򐂰 The storage group assigned as an extend storage group can also be defined as an overflow storage group. See the section on “Overflow storage groups” on page 23 for a description on overflow storage groups.

When you wish to enable an extend storage group, the only changes required are those to the storage group definition in ISMF. You do not need to update your ACS routines to add references to the extend storage group.

It is possible to use a single extend storage group for all other pool storage groups effectively a one-to-many, star configuration. You could also design a one-to-one, ring, configuration where each storage group extends to the next storage group in the ring. We illustrate these different configurations in Figure 2-11.

A star configuration of your pool storage groups will allow you the most flexibility for use. However, it does require that you are able to dedicate volumes to an extend pool. In a ring configuration, if a single storage group fills, it becomes unavailable as an extend storage group, and may also impact the storage group that follows it as data sets extend into it. The advantage of the ring configuration is that you will be making use of resources that are already allocated.

Figure 2-11 Possible storage group configurations

SG1 SG2 SG3 SG4 SG5 SG Extend SG1 SG2 SG4 SG5 SG3

You are not required to define an extend storage group for any storage group. You can define extend storage group(s) for just a subset of pool storage groups. Even if you choose a ring configuration, data sets from one storage group are only permitted to extend to the extend group defined for the storage group that holds the first extent of the data set.

If you can define extend storage groups, there may be advantages in defining the volumes in the extend storage group as large volumes. These volumes are always more likely to be under their storage groups high allocation threshold so are more likely to be chosen for selection for allocation. We discuss support for large volumes in “Large volume support” on page 40.

DFSMShsm space management will not be impacted by a data set having extended to an extend storage group. The first extent of any data set will still on exist on a volume that is in the original storage group and this determines how space management will process data sets.

DFSMShsm availability management may be impacted if you use concurrent processing or any other copy process based on underlying hardware functions. Before we introduced extend storage groups all extents of a data set had to reside in the same storage group so that storage groups were often based on the underlying device types.

With the use of an extend storage group, data sets can have extents in multiple storage groups. If you have previously configured separate storage groups for devices with different capabilities, for example RVAs and IBM TotalStorage Enterprise Storage Server (ESS), you need to consider what devices are added to your extend storage group and whether you require more than one extend storage group (potentially one per device type).

For example, if a data set extends across multiple storage groups and you request a concurrent copy using hardware functions — for example, SNAPSHOT and FLASHCOPY, or you use a volume copy mechanism such as PPRC or XRC — this will not be successful. You need to ensure that the copy method that you rely on can support a data set potentially allocated across a number of different control units.

If you are reliant on a hardware based copy solution, then you may need to define a number of extend storage groups, at least one per physical control unit, or ensure that your extend storage group contains volumes from each control unit. Allocation will favor volumes that meet requirements for specific hardware functions; we discuss this in “Summary of factors influencing volume selection” on page 35. But there are other factors, for example data set separation, that can outweigh these criteria.

Chapter 2. SMS enhancements 23

If you rely on DFSMSdss or DFSMShsm full volume dumps for data recovery, you will need to ensure that your extend storage group is processed at the same time as the storage group that contains the start of the data set. Failure to do this will result in either an incomplete copy of the data set or a non-synchronized copy.