This weekend we have to regenerate an SFS filepool that became much too big.As we do have processes that use the file creation and last referencedates, so we'd like to preserve them. When we tested this quite some monthsago we found a problem:- when we use VM:Backup to do a full restore, the creation date iskept, but the lastref date is set to the restore date.- when using FILEPOOL BACKUP/RESTORE, the last reference date is keptbut the creation date gets set to the restore date.My idea was to save the dates of all files (we have this ready) and usingDMSOPCAT, DMSRDCAT and DMSWRCAT to restore the last reference date. Butwhen I open the catalog for FILESPACE with intent READ, DMSRDCAT returns therecords in which I can find all file dates, but a DMSWRCAT is forbidden (cslreasoncode 56400); if I open the catalog for FILESPACE with intent WRITE, aDMSRDCAT directly fails with reason 56400.

If you run (VM:Backup) HiDRO ... All three dates for *files* arepreserved when they are restored. The only date that end up to be thedate of the restore/rebuild are the Create_Date for Directories. Thisis because they are "restored" by issuing the CREATE DIRECTORY COMMAND.

This weekend we have to regenerate an SFS filepool that became much toob=ig.As we do have processes that use the file creation and last referencedates, so we'd like to preserve them. When we tested this quite somemon=thsago we found a problem:- when we use VM:Backup to do a full restore, the creation date iskept, but the lastref date is set to the restore date.- when using FILEPOOL BACKUP/RESTORE, the last reference date is keptbut the creation date gets set to the restore date.My idea was to save the dates of all files (we have this ready) andusing=

DMSOPCAT, DMSRDCAT and DMSWRCAT to restore the last reference date. Butwhen I open the catalog for FILESPACE with intent READ, DMSRDCAT returns=therecords in which I can find all file dates, but a DMSWRCAT is forbidden(=cslreasoncode 56400); if I open the catalog for FILESPACE with intentWRITE,=aDMSRDCAT directly fails with reason 56400.

Yesterday I got a private note from Susan Farrel. And so I tested again:.... and I was proven wrong (or a bit wrong that is)- FILEPOOL BACKUP/RESTORE preserves all dates- FILEPOOL UNLOAD/RELOAD does not (the last-ref date is wrong)So, I'm surprized that the most recent tool is less good than the old onethat exists since VM/SP R6 days.

At the other hand, we already started installing HiDRO too. But I don'tknow if we will ever use it as we are somewhat in a hurry. And, FILEPOOLBACKUP/RESTORE also transparantly backups/restores files migrated byDFSMS. Does HiDRO supports that too?

If you run (VM:Backup) HiDRO ... All three dates for *files* arepreserved when they are restored. The only date that end up to be thedate of the restore/rebuild are the Create_Date for Directories. Thisis because they are "restored" by issuing the CREATE DIRECTORY COMMAND.

This weekend we have to regenerate an SFS filepool that became much toob=ig.As we do have processes that use the file creation and last referencedates, so we'd like to preserve them. When we tested this quite somemon=thsago we found a problem:- when we use VM:Backup to do a full restore, the creation date iskept, but the lastref date is set to the restore date.- when using FILEPOOL BACKUP/RESTORE, the last reference date is keptbut the creation date gets set to the restore date.My idea was to save the dates of all files (we have this ready) andusing=

DMSOPCAT, DMSRDCAT and DMSWRCAT to restore the last reference date. Butwhen I open the catalog for FILESPACE with intent READ, DMSRDCAT returns=therecords in which I can find all file dates, but a DMSWRCAT is forbidden(=cslreasoncode 56400); if I open the catalog for FILESPACE with intentWRITE,=aDMSRDCAT directly fails with reason 56400.

HiDRO supports preserving the "migrated shell" for each file that hasbeen migrated. Therefore after you RESTORE/REGENERATE your FilePool(s),touching a migrated file will trigger the RECALL mechanism of DFSMS asyou would expect.

When HiDRO backs up a FileSpace that contains migrated objects, amessage is put out stating that particular domain contains one or moremigrated objects.

Yesterday I got a private note from Susan Farrel. And so I testedagain: .... and I was proven wrong (or a bit wrong that is)- FILEPOOL BACKUP/RESTORE preserves all dates- FILEPOOL UNLOAD/RELOAD does not (the last-ref date is wrong)So, I'm surprized that the most recent tool is less good than the oldone that exists since VM/SP R6 days.

At the other hand, we already started installing HiDRO too. But I don'tknow if we will ever use it as we are somewhat in a hurry. And,FILEPOOL BACKUP/RESTORE also transparantly backups/restores filesmigrated by DFSMS. Does HiDRO supports that too?

ToVMESA-***@LISTSERV.UARK.EDUccSubjectRe: Preserving SFS last reference date across a restore

Kris,

If you run (VM:Backup) HiDRO ... All three dates for *files* arepreserved when they are restored. The only date that end up to be thedate of the restore/rebuild are the Create_Date for Directories. Thisis because they are "restored" by issuing the CREATE DIRECTORY COMMAND.

This weekend we have to regenerate an SFS filepool that became much toob=ig.As we do have processes that use the file creation and last referencedates, so we'd like to preserve them. When we tested this quite somemon=thsago we found a problem:- when we use VM:Backup to do a full restore, the creation date iskept, but the lastref date is set to the restore date.- when using FILEPOOL BACKUP/RESTORE, the last reference date is keptbut the creation date gets set to the restore date.My idea was to save the dates of all files (we have this ready) andusing=

DMSOPCAT, DMSRDCAT and DMSWRCAT to restore the last reference date. Butwhen I open the catalog for FILESPACE with intent READ, DMSRDCAT returns=therecords in which I can find all file dates, but a DMSWRCAT is forbidden(=cslreasoncode 56400); if I open the catalog for FILESPACE with intentWRITE,=aDMSRDCAT directly fails with reason 56400.