HMIG default for explicit command migration is ML1. If you explicitly
say ML2 then you are saying migrate to ML2 and that's what it does. As
previously mentioned, Migration Attributes for primary and level 1 only
apply to auto migration. Manual migration assumes you want what you ask
for.
As others have already stated, you really need to assign system datasets
that should not be subject to auto migration to a distinct management
class that doesn't allow it. That's how management classes are intended
to be used. If they will never be re-allocated, you can simply use
ALTER (TSO or batch IDCAMS) to alter the management class of existing
datasets. If they will be reallocated, modify your ACS routines or use
RACF profile attributes to influence the ACS routines to change the
MGMTCLAS when system datasets are allocated. Long-term it might be
better to use a distinct naming convention to make it easier to separate
the system datasets that should get different treatment.
Joel C. Ewing
On 11/19/2010 09:44 AM, willie bunter wrote:
Ron& Ted,
Believe you me I have addressed this situation in the past but the mind set
being stuck in the 20th century I have had no success.
Last question given the present set up:
Migration Attributes
Primary Days Non-usage . : 3
Level 1 Days Date/Days . : 2
Command or Auto Migrate . : BOTH
How can I just migrate to ML1? For a test I issued the command but the dsn was
migrated to ML2 even thought the Level 1 days has a value of 2?
--- On Fri, 11/19/10, Ron Hawkins<[email protected]> wrote:
From: Ron Hawkins<[email protected]>
Subject: Re: DFHSM MIGRATE MYSTERY
To: [email protected]
Received: Friday, November 19, 2010, 7:11 AM
Willie,
But that's why we have Migration Classes. The idea behind SMS is to allow
your policies to operate at the dataset level.
Why not put the system files in a migration class with no auto migration,
and let DFHSM manage the other stuff?
Ron
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of
willie bunter
Sent: Friday, November 19, 2010 6:51 AM
To: [email protected]
Subject: Re: [IBM-MAIN] DFHSM MIGRATE MYSTERY
Stan,
Thanks for the clarification that Command migrate will supersede the SMS
attributes. The reason why this particular Storage group is exempted from
Space Management is because there are several system files which reside in
this storage group. Exempting them from migration could open the door for
other unforseen problems.
Thanks.
--- On Fri, 11/19/10, Stan Weyman<[email protected]> wrote:
From: Stan Weyman<[email protected]>
Subject: Re: DFHSM MIGRATE MYSTERY
To: [email protected]
Received: Friday, November 19, 2010, 6:43 AM
Command migration is going to do what you tell it to do regardless of
the
SMS attributes. Why not let SMS manage these datasets?
Stan Weyman
Senior Software Engineer
[email protected]
EMC² (508)249-3966
where information lives
It is wise to keep in mind that neither
success nor failure is ever final...
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of
willie bunter
Sent: Friday, November 19, 2010 9:01 AM
To: [email protected]
Subject: DFHSM MIGRATE MYSTERY
Hallo To All,
I came across a problem where dsns are not being migrated from a given
Storage
Group. The STORAGE GROUP is SMS managed but it is exempt from Auto
Migrate.
A batch job is executed weekly to manually migrate the dsns - below is the
command :
HMIG 'SYS2.B*.HISTORY.D*.T*' ML2
Below is the construct of this particular Management Class
Expiration Attributes
Expire after Days Non-usage . : 55
Expire after Date/Days . . . . : 55
Retention Limit . . . . . . . : NOLIMIT
Migration Attributes
Primary Days Non-usage . : 3
Level 1 Days Date/Days . : 0
Command or Auto Migrate . : BOTH
When the batch job is executed all the dsns (these are all VSAM dsns) are
migrated ML2 - including those that were created this morning before the
migrate was done. According to the Migration Attributes shouldn't those
dsns
which were created today& yesterday not be migrated?
Could someone help me understand where else I should look.
Thanks in advance for your help.
--
Joel C. Ewing, Fort Smith, AR [email protected]
----------------------------------------------------------------------
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
