Well, if there is no migration then adjusting the thresholds will not get you much. The only space that will be released will be from those files that are over-allocated or expired. In this case, then you have to look at the files to make sure that you have no un-cataloged files, these will take up space but will never go away. Also, if you have GDGs with an expiration date, these may stay around even though they are not in the base and this is governed by the "rolled off gds action" attribute in the management class; In other words, you have to get to know the data much better to determine if there is space that should be released. Another way to release space on a file is by the use of "partial release" attribute on the management class. Also, files that are "Fixed" instead of fixed-blocked will waste quite a bit of space.
Hervey -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of willie bunter Sent: Thursday, January 05, 2012 1:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: DFHSM QUESTION : Allocation/migration Threshold I should have mentioned that there is no ML0/ML1 migration in this pool as well. PSM is only being run. I understand that this is not a good thing but the client insists upon having NO migration of the dsns from this pool this woould explain why the Threshold is low. Would adjusting the Threshold help eventhough there is no migration? ________________________________ From: Hervey Martinez <hervey.marti...@custserv.com> To: IBM-MAIN@bama.ua.edu Sent: Thursday, January 5, 2012 9:46:34 AM Subject: Re: DFHSM QUESTION : Allocation/migration Threshold If there is no ML2 migration then everything is migrating to the ML1 pool and the ML1 pool may be full; if so, then it needs to be expanded. Normally, ML2 migration is governed by the management class; so, how do you keep this pool from ML2 migration? Also, Interval migration runs every hour on the hour provided that PSM & SSM are not running and it uses the mid-point of your hi-lo threshold; thus, your pool will start migrating around 36% capacity during interval migration. Thanks, Hervey 813.878.6097 -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Staller, Allan Sent: Thursday, January 05, 2012 9:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: DFHSM QUESTION : Allocation/migration Threshold Migration will begin when the SG occupancy exceeds the high threshold and continue until less than the SG low threshold, or no additional datasets are eligible for migration. This is subject to additional constraints specified in the MGMTCLAS for migration eligibility. IMO your low thresholds are "too low" causing "thrashing" (needless migration/recall of dataset due to interval migration), which will compound the . Your high thresholds seem pretty good. As presented, every migration "empties" the pool, and dataset reference fills it back up. There is an art to setting thresholds. A thorough analysis, taking into consideration the MGMTCLAS(s), STORGRP(s), thresholds, relative data set sizes, and reference patterns needs to occur. HTH, <snip> I have a problem with a SMS managed storage pool which is increasing quite rapidly. In this pool there is no ML2 migration . We have Auto Migrate & Auto Backup turned on and INTERVAL MIGRATION. Below is the THRESHOLD which we are using for this pool. Allocation/migration Threshold : High . . 75 (1-99) Low . . 3 (0-99) Alloc/Migr Threshold Track-Managed: High . . 85 (1-99) Low . . 1 (0-99) If I lowered the THRESHOLD would that help and free up some space? </snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
