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
