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
