Comments (1)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 Peter_Wilson commented Permalink

The Storgrp High Threshold may be a large factor in this as DFSMS uses this in the volume selection process as well as it being the DFHSM Migration trigger point. The SMS Primary selection list eliminates volumes where the allocation would take them over that high threshold and drops them into a Secondary list. So if many volumes are over the threshold there's going to be numerous allocation re-drives through SMS resorting to the Secondary list. This must incur some overhead, although it's hard to find definitive statements about this. It's hinted at by the introduction of the Fast_Volume_Selection option to address long allocation delays, especially where large numbers of volumes are involved. Larger sized volumes would certainly help reduce this issue. <div>&nbsp;</div> Another possible useful feature if you have 2 or 3 storgrps is the Tiered Storgrps. By having these concatenated in order you will have larger datasets gravitate to one storgrp and smaller ones to the other. It requires a Storclas setting to be in place to work. <br /> e.g. <br /> concatenation order &amp;STORGRP='SG1','SG2' for larger datasets means SG1 is preferred. concatenation order &amp;STORGRP='SG2','SG1' for smaller ones means SG2 is preferred. <br /> If a 3rd storgrp was introduced into the middle of the concatenation you could expect that to absorb medium allocations. <div>&nbsp;</div> I'm not quite sure how the sliding secondaries affect all this.