OS/390 System Managed Storage - Storage Group

Storage groups are the fundamental concept of DFSMS. Mainframe disks are limited in size to about 8GB each, though 25GB 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.
A few tips about storage pools

How many pools?

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. That's 9 pools. You will also need a few special pools for system data 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 &STORGRP='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.

back to top

By entering and using this site, you accept the conditions and limitations of use