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 <[email protected]> wrote:


From: Joel C. Ewing <[email protected]>
Subject: Re: DFHSM MIGRATE MYSTERY
To: [email protected]
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<[email protected]>  wrote:
>
>
> From: Mike Schwab<[email protected]>
> Subject: Re: DFHSM MIGRATE MYSTERY
> To: [email protected]
> 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<[email protected]>  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        [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




----------------------------------------------------------------------
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

Reply via email to