Thanks for all the valuable feedback. I see no dumps using RESET on this data. 
It looks like time to initiate an SR with IBM.

The patch looks like it's just what we need to find out why they're being 
overlooked.


David G. Schlecht | Information Technology Professional
State of Nevada | Department of Administration | Enterprise IT Services
T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joel C. Ewing
Sent: Wednesday, July 17, 2013 8:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Missing HSM backups

I would put it a little more strongly than Richard:
If you are using HSM auto backup, make it an installation standard to NOT use 
the RESET option on DFDSS DUMP or you will at some point fail to get an 
expected HSM backup, which, if actually required, is in effect a DATA LOSS.

If you have HSM Fast Subsequent Migration enabled, DO NOT use the RESET option 
on DFDSS DUMP.  Perhaps HSM is now smarter, but it at least used to be the case 
that this could cause DATA LOSS for datasets that had been recalled from ML2 
and subsequently changed!!!  A dataset that was RECALLED from ML2, changed, and 
then has its "changed" flag reset by DUMP ... RESET or any other utility was 
erroneously assumed by DFHSM to be identical to the old copy on ML2, and if 
migrated to ML2 while the old copy still existed physically, the old ML2 copy 
was re-activated as valid and the changed live copy deleted, resulting in DATA 
LOSS.

In 2007 it was discovered (through a reporting on IBM-MAIN of the ML2 DATA LOSS 
scenario above) that DFDSS full volume RESTORE had for years been erroneously 
resetting changed flags on datasets, in effect invalidating usage of DFDSS for 
moving DASD volumes or for DR volume recovery in shops relying on DFHSM auto 
backup or with HSM Fast Subsequent Migration enabled.  After much discussion on 
this group and offline with IBM, the initial Docs change response was replaced 
by an optional patch, and finally permanently resolved to eliminate the 
exposure by a fix now reflected in the DFSMSdss Storage Administration Guide 
under "DFSMSdss handling of the data-set-changed indicator during restore".
        Joel C. Ewing

On 07/17/2013 06:12 AM, Richard Marchant wrote:
> New David and original David,
> 
> You are correct you can add the RESET parameter to a DSS dump be it 
> dataset(s) or a volume and this resets the Last Changed flags. HSM autobackup 
> comes along and will not backup these dataset(s) again unless changed in the 
> interim (assuming you have HSM set to INCREMENTAL).
> 
> HSM dumps can also have the same effect if you have RESET in the appropriate 
> DUMPCLASS. 
> 
> BEWARE!
> 
> Richard
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of David Devine
> Sent: Wednesday, July 17, 2013 11:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Missing HSM backups
> 
> Hello Richard,
> 
> there is a diagnostic patch mentioned in one of the share "Managing Hsm....." 
> sessions which should show up why datasets are not being backed up.
> You are only supposed to use it at IBM's request but it seems that you are at 
> the point anyway.
> 
>   • PATCH .BGCB.+24 X'FF'
> • Used to determine why SMS-managed data sets are not being selected 
> during volume backup • These patches produce a lot of messages • 
> ARC1245I with Reason Codes GT 90 for migrations • ARC1334I with Reason 
> Codes GT 90 for backups
> 
> I've not used it so personally so exercise some caution and give it a whirl 
> on your sysprog lpar first after you've checked it out.
> 
> Also i've a vague memory of an issue with volume dump jobs running against 
> packs (or it might have been defrag/compactor type jobs ) which is re-setting 
> the dataset backed up flag in the vtoc so hsm wont back it up.
> 
> So i would check what activity went on against the pack in question where 
> your dsn didnt get backed up in the time between dsn creation and hsm backup.
> 
> Regards
>              Dave
>          
> 
> 
> 
> 
> 
> 
> 
> 
> **********************************************************************
> *************************
> 
> Richard,
> 
> The two datasets are in the same management class in the same storage group 
> but on different packs.
> 
> 
> David G. Schlecht | Information Technology Professional State of 
> Nevada | Department of Administration | Enterprise IT Services
> T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov
> 
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Richard Marchant
> Sent: Tuesday, July 16, 2013 12:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Missing HSM backups
> 
> David,
> 
> Where are the two GDGs located? Are they on different SMS groups or different 
> non-SMS volumes? If they are separated are you allowing HSM to perform 
> autobackup on both entities? 
> 
> Richard
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of David G. Schlecht
> Sent: Monday, July 15, 2013 6:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Missing HSM backups
> 
> We have two lpars plexed, sharing DASD and catalogs and run HSM on each. 
> Lpar-1 is supposed to handle the backups.
> Lpar-1: AUTOBACKUPSTART(1700 1800 1900)
> Lpar-2: AUTOBACKUPSTART(0000 0000 0000)
> 
> Backups start at 17:00 and typically end around 17:11, hence, it seems 
> sufficient time is provided.
> 
> 
> David G. Schlecht | Information Technology Professional State of 
> Nevada | Department of Administration | Enterprise IT Services
> T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov
> 
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Ulrich Krueger
> Sent: Monday, July 15, 2013 9:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Missing HSM backups
> 
> David,
> Is it possible that your time window for DFHSM backups is not long enough for 
> the incremental backups to complete? 
> 
> 
> Regards,
> Ulrich Krueger
> 
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of David G. Schlecht
> Sent: Monday, July 15, 2013 9:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Missing HSM backups
> 
> A new wrinkle and possibly related. I have a job that creates two GDGs in the 
> same Management Class. Both should be backed up. However, one gets backed up 
> while the other doesn't. The backup for the first shows up in HSM's job logs 
> at the point of backup but the second is entirely absent from HSM logs.
> 
> Even if HSM is having trouble backing up a dataset, shouldn't it be showing 
> up in the job logs?
> 
> 
> 
> 
> David G. Schlecht | Information Technology Professional State of 
> Nevada | Department of Administration | Enterprise IT Services
> T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov
> 


-- 
Joel C. Ewing,    Bentonville, AR       jcew...@acm.org 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to