DFSMS, z/OS System Managed Storage - Storage Group

Storage groups are the fundamental concept of DFSMS. Mainframe disks are 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.
A few tips about storage pools

How many pools?

I'd suggest that you do not put data under SMS for the sake of it, or just because you can. Use SMS where you will see a benefit.

In general, the bigger the pool the better. Try to avoid lots of small pools. Why? Because you can run a large pool at a higher occupancy level without space problems, and that saves money. If you have a 5 volume pool which holds 40GB, then 20% free space is 8GB. That is not a lot, especially when the space gets fragmented. If you run a 500GB pool at 90% occupancy, then you have 50GB free. What's right for the occupancy level depends very much on the type of data in the pool. Databases tends to be well behaved and predictable, so large database pools can be run at 90% to 95%. General purpose pools can be volatile, and need more free space. You need to analyse your own pool usage and see what's best for your site.
So how many pools? One suggestion is to split your data into three, Production, Development and Test. Within each section you would have three pools, large and small allocations, and an overflow pool. It is also a good idea to have a separate pool for databases, so that's 10 pools. You will also need a few special pools for system data, VIO pools and the like.

What are large/small/overflow pools? A large pool basically holds files with large allocations, and a small one with small allocations. Then when datasets are deleted, they leave small holes in the small pool, and large holes in the large pool. If you mix them, small datasets will clog the disks up, and leave the free space fragmented, so large datasets cannot be allocated. Separating them avoids space abends and reduces the need for defragmentation jobs. You can also avoid space abends by keeping a small number of volumes empty(ish), to be used when the other volumes fill up. DFSMS implements this by letting you define volumes in QUINEW status, which means 'Quiesce New'. These disks will only be used when the ENABLE'd volumes are full. However, its much more efficient to keep one small pool of quiesced volumes, rather than having quiesced volumes in every pool. This is the overflow pool. DFSMS has no concept of an overflow pool per se. To make it work, you must have ALL the volumes ENABLED in your primary pools, and all the volumes QUIESCED in your overflow pool. You then concatenate the overflow pool with your primary pools, using ACS code like this

  WHEN (&SIZE GE 75MB) DO
     SET &TORGRP='LARGE','OVERFLOW'
     EXIT
  		       END
  OTHERWISE DO
     SET &STORGRP='SMALL','OVERFLOW'
     EXIT
            END

Storgrp ACS variables

Some of the read only variables that are used in the other ACS routines, are not allowed in the storage group routine. These are:-

• &ACCT_JOB
• &ACCT_STEP
• &DD
• &JOB
• &MSVGP
• &PGM
• &XMODE

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.

Volume Selection Order

When it gets an allocation request, SMS checks out all available volumes are draws up four lists

1. The Reject list contains all volumes that do not match the required criteria for the allocation. These volumes will not be used by SMS
2. The Primary list contains online volumes with used space below the threshold and that meets all the allocation criteria
3. The Secondary list contains volumes that are online, but do not meet all the criteria
4. The Tertiary list is set up if if there are not enough volumes available in the pool to meet the requested number

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.

back to top

Copyright © Lascon Storage Ltd. 2000 to present date. By entering and using this site, you accept the conditions and limitations of use