Esmie, No, eligible datasets will be moved to ML2 otherwise datasets will be moved to ML1 volumes.
However to verify that the above answer is correct I ran the command against my ML1 volume with the most free extents and got the following: ARC0523I SPACE MANAGEMENT ENDED ON VOLUME HSM113, 719 ARC0523I (CONT.) 00000380 DATA SET(S) MIGRATED/DELETED, 00041473 ARC0523I (CONT.) TRACK(S) FREED, MINAGE 7, TIME 10:55:38 Only 1 dataset was moved to ML2. HTH ________________________________________ From: esmie moo [EMAIL PROTECTED] Sent: Tuesday, October 14, 2008 10:35 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DFHSM QUESTION - ML1 David, Please correct me if I am wrong regarding the Freevol MVOL(nnnnnn) TARGETLEVEL(ML2) command. If this command is issued then all dsns be migrated despite the Management class rules? Thanks. --- On Sat, 10/11/08, O'Brien, David W. (NIH/CIT) [C] <[EMAIL PROTECTED]> wrote: From: O'Brien, David W. (NIH/CIT) [C] <[EMAIL PROTECTED]> Subject: Re: DFHSM QUESTION - ML1 To: IBM-MAIN@BAMA.UA.EDU Received: Saturday, October 11, 2008, 5:53 AM Willie, It might help to know a bit more about your environment. What are the following: >From HSM - Days, ML1days (or Migrationlevel1days) >From SMS - Primary Days, Level 1 days Are your tapes operator mounted or in a Silo? My silo recalls average 27 secs. Nobody complains. If the same recalls were operator mounted, my ML1 pool would be much larger. To avoid the type of problem you describe I issue a Freevol MVOL(nnnnnn) TARGETLEVEL(ML2) against the ML1 volume that has the highest Frag Index. I do this daily early in the AM. to avoid contention. ________________________________________ From: willie bunter [EMAIL PROTECTED] Sent: Friday, October 10, 2008 12:38 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DFHSM QUESTION - ML1 David, You have answered my question. I wanted to be sure. We had an incident (ML1 threshold was 80%) ARC0560E NO MIGRATION LEVEL 1 SPACE ARC0560E AVAILABLE. Since we did not want to add another ML1 volume we decided to reduce the threshold and forced the Secondary Space Management. It did solve the problem temporarily. However, we had the same problem a day later. As a work around, I changed the Management class of some dsns, perform a ML2 migrate and changed back the Management class. Is there another way of handling this situation? --- On Fri, 10/10/08, O'Brien, David W. (NIH/CIT) [C] <[EMAIL PROTECTED]> wrote: From: O'Brien, David W. (NIH/CIT) [C] <[EMAIL PROTECTED]> Subject: Re: DFHSM QUESTION - ML1 To: IBM-MAIN@BAMA.UA.EDU Date: Friday, October 10, 2008, 8:58 AM ML1 threshold as specified in the HSM Parmlib Addvol statement specifies the point at which that volume becomes eligible for migration. If a dataset is on a ML1 volume which is 50% full and your threshold for that volume is 80% then that dataset will not be migrated to ML2 even though its management class may indicate that it is eligible. Perhaps I'm reading your query incorrectly. A dataset which according to its management class should be on ML1 will stay on ML1 even if the ML1 volume %used is 90%. That's why after Secondary Space Mgmt. some ML1 volumes remain above the defined threshold for the ML1 volumes. ________________________________________ From: willie bunter [EMAIL PROTECTED] Sent: Friday, October 10, 2008 11:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: DFHSM QUESTION - ML1 Hallo To All, Our ML1 volumes threshold is set to 80%. My question is does the Management class takes precedence over the threshold. For example, if I change the threshold to 50% would it result in the ML1 volumes being 50% full (after Secondary space management has kicked in) or will the respective Management classes prevent that from happening? I hope I am able to explain myself clearly. Thanks ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html __________________________________________________________________ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html