Joel,
We finally found the reason to this problem. There is an exit placed so as to
prevent certain HLQ qualifiers migration to ML1 from ML0. This exit was placed
by the customer in the ARCMD9 parmlib. I was convinced that there was a
problem with the Management Class settings. I am guilty of leaping before I
looked. A lesson well learned.
Thanks again to you and all those posters who took the time to answer my
question.
--- On Sat, 11/27/10, Joel C. Ewing <jcew...@acm.org> wrote:
From: Joel C. Ewing <jcew...@acm.org>
Subject: Re: DFHSM MIGRATE MYSTERY
To: IBM-MAIN@bama.ua.edu
Received: Saturday, November 27, 2010, 10:42 AM
If everything is as you described, I'm not sure why your system should behave
differently than mine. Perhaps there is some subtle parameter in HSM that I've
forgotten about, but the rules as I understand them and as they work on my
configuration are:
MGMTCLAS "Primary Days" and "Level 1" days only apply to space management
auto-migration and are ignored when command (HMIG) migration is used. Other
MGMTCLAS attributes, such as auto-backup, continue to be honored and are
unaffected by whether HMIG is used or not.
If auto-backup is turned off, HMIG does not check to see if any backups exist
and
HMIG dataset will move dataset on primary to ML1
HMIG dataset ML2 will move dataset on primary or ML1 to ML2
If auto-backup is turned on, and no backup exists
HMIG dataset will move dataset on primary to ML1
HMIG dataset ML2 will fail with ARC1280I if dataset on
primary or ML1 and no move is done
If auto-backup is turned on, and backup exists
HMIG dataset will move dataset on primary to ML1
HMIG dataset ML2 will move dataset on primary or ML1 to ML2
If I understand your previous posts correctly, you indicated that with
auto-backup on and no backup yet, "HMIG dsn ML2" migrated the dataset to ML1.
This does not happen on my system. I get ARC1280I and no migration for this
case. I would get a migration to ML1 and no error only if the command "HMIG
dsn" (with no "ML2") had been used under those conditions. The primary and
level 1 days in MGMTCLAS are irrelevant to HMIG operation in either case - they
only affect auto-migration.
On most recent case indicated, where a backup is known to exist, the command
"HMIG dsn ML2" should always force migration to ML2. You don't explicitly say
whether in the last case your dataset ends up on ML2 or ML1, but on my system
it ends up on ML2 and this is where the documentation says it should end up.
Again the primary and level 1 days in MGMTCLAS are irrelevant to HMIG operation
- they only affect auto-migration.
This is the behavior of the HMIGRATE command as documented in Chapter 18,
"DFHSM Managing your Own Data":
"The data set migrates to a level 1 migration volume unless you specify the
MIGRATIONLEVEL2 parameter in the command or you are in an environment that
migrates directly to migration level 2 volumes" [this latter reference is to an
HSM system with no ML1 space defined, which is obviously not the case in the
current discussions - JCE]
and
"... MIGRATIONLEVEL2 is an optional parameter you use to migrate a data set
from a level 0 volume or a migration level 1 volume to a migration level 2
volume. The MIGRATIONLEVEL2 parameter must be specified if you are migrating an
already migrated data set."
Note there is NO mention of any interaction with the MGMTCLAS definitions.
Don't assume an interaction when none is documented.
The descriptions of the MGMTCLAS options for primary and level 1 days in "DFSMS
Storage Administration Reference" are perhaps not as clearly worded as they
could be. These are documented as applying to "normal" migration. In this
context "normal" means space management or auto-migration. In other words,
these parameters do NOT apply to manual command migration, which is only
designed to handle exceptions to "normal" processing.
This is the way MGMTCLAS and HMIGRATE are designed to interact and the way they
do interact on my z/OS system.
Joel C. Ewing
On 11/24/2010 10:45 AM, willie bunter wrote:
> Joel,
>
> I did a manual BACKDS command of the dsn. Next I did a LISTCAT of the dsn
> and it shows LBACKUP ---2010.328.0643. I did a HMIG dsn ML2 . I did a
> LISTCAT again and it shows LBACKUP ---XXXX.XXX.XXXX
> However when I do HLIST of the dsn it shows the backup 10/11/24 06:43:55
> I am not sure why this is happening. I also noted that if I issue the HMIG
> dsn ML2 the MANAGEMENT CLASS Migration Attributes is being ignored even
> though I have specified
> the following:
> Primary Days Non-usage . : 3
> Level 1 Days Date/Days . : 2
> Command or Auto Migrate . : BOTH
>
> As an earlier poster had mentioned that if a manual Migrate ML2 command is
> issued to migrate the dsn, it overrides the Migration attributes. This
> storage group is exempt from Auto Migrate but it does have Auto Backup turned
> on. I noticed that the Auto Backup is working. The dataset in question was
> not backed up because it was created after the Auto Backup had run.
>
>
> --- On Tue, 11/23/10, Joel C. Ewing<jcew...@acm.org> wrote:
>
>
> From: Joel C. Ewing<jcew...@acm.org>
> Subject: Re: DFHSM MIGRATE MYSTERY
> To: IBM-MAIN@bama.ua.edu
> Received: Tuesday, November 23, 2010, 4:04 PM
>
>
> Did you display the LBACKUP date while the file was migrated? On z/OS
> 1.10 I only see the actual last Backup date displayed if the dataset is
> on a primary volume. If on ML1 or ML2 neither ISMF no LISTC will
> display the backup date.
>
> Did you do a
> "HMIG dsnamefilter"
> (which is a request to migrate to ML1) or
> "HMIG dsnamefilter ML2"?
>
> If I try to migrate a dsn with an autobackup management class to ML2 and
> there is no backup yet, it fails with "ARC1280I MIGRATION FAILED - DATA
> SET IS IN NEED OF BACKUP". If I try to migrate the same dataset to ML1
> ("ML2" parm omitted), migration succeeds. I think this is because DFHSM
> can still do an autobackup from ML1. Or If I then attempt to force a
> migrate from ML1 to ML2 with "HMIG dsname ML2" before there is a backup,
> I also get the ARC1280I failure.
>
>
> On 11/22/2010 07:51 AM, willie bunter wrote:
>> Mike,
>>
>> I took your advice and set the MANAGEMENT CLASS AUTO BACKUP=Y.
>>
>> As a test I created a new dsn using the same HLQ's and Management Class. I
>> tried the MIGRATE command via batch (using wild cards) it went to ML1
>> instead of ML2 which was NOT happening before I changed the AUTO BACKUP from
>> N to Y. I did a LISTCAT of the dsn but it shows that no backup was done.
>> Inspite of this the dsn was sent to ML1. Not sure why
>> LBACKUP ---0000.000.0000
>>
>> If I understand Joel's post correctly in which he says that "Migration
>> Attributes for primary and level 1 only apply to auto migration" then the
>> dsn should not have been sent to ML1 but directly to ML2.
>>
>> Any suggestions?
>>
>> --- On Fri, 11/19/10, Mike Schwab<mike.a.sch...@gmail.com> wrote:
>>
>>
>> From: Mike Schwab<mike.a.sch...@gmail.com>
>> Subject: Re: DFHSM MIGRATE MYSTERY
>> To: IBM-MAIN@bama.ua.edu
>> Received: Friday, November 19, 2010, 10:39 AM
>>
>>
>> You can requre that a successful SMS backup before it allows the
>> dataset to be migrated.
>>
>> On Fri, Nov 19, 2010 at 8:00 AM, willie
>> bunter<williebun...@yahoo.com> wrote:
>> <deleted>
>>> 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 jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
