- z/OS file structures
- DFSMS on z/OS
- Data Class
- Management Class
- Storage Class
- Storage Group
- ACS routines
- z/OS performance
- z/OS file utilities
- z/OS SMF statistics
- z/OS RMF reporting
Storage groups are the fundamental concept of DFSMS. Mainframe disks were limited in size to about 8GB each, though much larger disks are now available. In the old days, you had to decide which disk you were going to place your file on, and hope it had enough space available. Space errors were common, especially in batchwork. DFSMS groups disks together into storage pools, so you allocated by storage pool. Its much easier to maintain free space in a pool of 50 disks. Storage pools can also consist of tape volumes (not tape files) and optical volumes. This allows SMS to direct tape allocations to a VTS or automated library.
The different types of storage pool that you can define are:
You need to define your volumes as being DFDSMS capable, then you add them to your storage pools. There are some simple rules regarding storage pools, volumes and datasets.
When you are initialising new volumes, the easiest way to prepare them for SMS is to use the STORAGEGROUP keyword in your ICKDSF job like this
INIT UNIT(D615) VOLID(D3D615) VTOC(1,0,270) -
INDEX(0,1,14) VFY(OLDVOL) -
If you want to know what volumes are defined to an existing storage class, the easiest way is to use the SDSF command
However access to these commands is often restricted. If you do not have access, the other way is to use the ISMF panels.
Select the Storage Group option 6 from the ISMF Primary Option Menu
Select option 1, List and this will list out all the storage groups.
Type LISTVOL in the Line Operator column next to a storage group that you are interested in and this will list out all the volumes.
There is a special type of storage pool called 'Reserve storage pools' that you can use as a place to hold volumes that have been initialised and formatted for SMS, but you do not want them to be used at this time.
You initialise reserved volumes with ICKDSF, but add a RESERVED parameter and an OWNERID parameter. The OWNERID should be called IBMRSPrespoolname, where respoolname is the name of the reserved storage pool. The reserved volumes will be offline and cannot be brought online until they are re-initialised without the RESERVED parameter.
When you define a Storage Group for Tape, all you define is a list of at least one, and up to 8 libraries that belong to that Storage Group, and the SG status. You do not define drives or tape volumes. You can define up to 15 SGs with 8 libraries each.
When the Storage Group ACS routine gets a new tape allocation, it assigns it to a tape storage group, then selects a tape library and a tape device pool, then a specific tape drive is picked out from the tape device pool. A tape device pool is a string of tape drives attached to a single control unit.
I used to recommende using a small number of large storage pools, as that meant they could be run at high occupancy with a minimum risk of space abends. That idea is a little old fashioned now, with the advent of thin volumes. Thin volumes are allocated into pools of storage on a disk subsystem, but each volume will use the space needed for the data stored on it. In other words, you can allocate a 233 GB EAV volume, but if that volume only has a 1 track dataset on it, it will only use a few KB of space. Filling logical volumes up is no longer important.
What is very important these days is availability of service.
It therefore makes a lot of sense store applications on their own storage pools, so if anything goes wrong, then any impact is limited to that application. It might also make sense to group some applications together, where one business area runs its own set of applications. This process requires a good understanding of your business, and how the applications fit together and interact.
The concept of overflow storage pools still applies, and DFSMS has two parameters to assist with this now, Extend Storage Group and Overflow Storage Group.
You would define an Overflow Storage Group by setting the parameter 'Is this pool an Overflow pool, to 'Y'.
Then for a primary storage group you can allocate an overflow, by setting the 'Extend Storage Group' parameter with the name of a storage pool that data on this pool can extend onto.
An Extent pool is just one other pool that allocations can go to if the primary pool is full. 2 primary pools can be defined so that they extend onto each other. Generally speaking, extend or overflow storage groups should not be used in a copy pool environment, unless all the primary, extend and overflow pools are all contained within the same copy pools. An Extend pool does not need any ACS routine processing.
To use an 'Overflow' pool, they must be concatenated with a primary pool in the ACS routine like this:
SET &STORGRP = 'Primary', 'Overflow'
Those names are examples, and you should use better, more meaningful ones. SMS will prefer to use volumes in the primary pool for an allocation (primary list, see below), but if that pool in over its threshold, then it will use the overflow pool (secondary list, see below. This assumes that all the volumes have identical performance characteristics). An overflow storage group may also be specified as an extend storage group. There is no need to quiesce the overflow pool volumes, in fact volumes residing in overflow storage groups are preferred over quiesced volumes and storage groups. However if you do quiesce your overflow pool, or some of your overflow pool volumes, then Primary quiesced volumes will be used before Overflow quiesced volumes
Storage pools should have similar performance characteristics, and you can define a heirarchy, or set of storage tiers, by setting the storage Class parameter, 'Will this Storage Class use a Multi-Tiered SG' to 'Y'. For this to work, you need concatenated storage pools in your ACS routines, but you can concatenate several pools and they will be used in order. I think the possible number of pools is something ridiculous like 256. Let's assume you have 4 pools concatenated, your storage class has Multi-Tiered SG 'Y' and that storage class picks up the concatenated pool code like this;
SET &STORGRP = 'SG1', 'SG2', 'SG3', 'SG4'
Now SMS will use SG1 for allocations, unless all its enabled volumes exceed the high threshold, in which case it will go to SG2. If that pool is full it will try SG3, then if SG3 is full it will try SG4.
You can define alert thresholds for entire SMS storage groups. 2 thresholds are available:
Total Space Alert Threshold %
Track-Managed Space Alert Threshold %
When a volume is varied on or offline; or when a file is added, extended or deleted so that the pool spave changes, SMS calculates the overall space usage of the storage pool and will issue an alert message of either of the thresholds are exceeded.
Some of the read only variables that are used in the other ACS routines, are not allowed in the storage group routine. These are:-
The problem is that if you use one of these variables in your ACS code, you get the error message
IGD03111I INVALID REFERENCE TO READ/ONLY VARIABLE &JOB
when you compile the code. The message is a little ambiguous, something like
VARIABLE &JOB NOT ALLOWED IN STORGRP ROUTINE
would be a bit easier to interpret.
When it gets an allocation request, SMS checks out all available volumes are draws up four lists
SMS will first try to select volumes from the Primary list, using SRM to select the volume with the lowest device delay first. If there are not enough volumes in the primary list, then SMS selects at random from the Secondary list, then the Tertiary list. If the request is for a striped dataset, then SMS will initially try to pick volumes that are under different controllers.
If you use DFHSM to backup and migrate data, then you need to set AUTO MIGRATE, AUTO BACKUP and AUTO DUMP parameters for each pool.
AUTO MIGRATE determines if the DASD volumes in this Storage Group are eligible for automatic space management processing, which includes things like deletion of temporary datasets, release of unused, over-allocated space, and migration of files off primary disk if they have not been used for a while. Possible values are YES, NO, INTERVAL, or PRIMARY
AUTO BACKUP determines if the volumes in this Storage Group are eligible for DFSMShsm incremental backup. Possible values are YES or NO.
AUTO DUMP determines if volumes in this Storage Group can be automatically dumped using DFSMShsm. Possible values are YES or NO.
See the DFHSM section for more details
back to top