The RestoreDate attribute wouldn't be worth much if it could be changed to any desired value. It would possibly be irresponsible to describe in a public forum a method of restoring an object and obscuring its RestoreDate attribute. With that said and out of the way... There might be ways of doing what you need. E.g., it's potentially possible that a restore from SAVSTG might retain old RestoreDates -- I haven't done such a restore in the past ten years and didn't check. I sure wouldn't count on it. You might be able to (1) rename LIBA to LIBAprevious, then (2) RSTLIB LIBA for a test, then (3) delete LIBA and (4) rename the old library back. That kind of procedure obviously requires extra space, but objects within LIBA should look at the end pretty much exactly like they did at the beginning. Unfortunately, it's a pretty small part of an entire DR test. The basics of that thought might spark other more complete ideas. You might run a controlled DSPOBJD *ALL/*ALL to an outfile in order to create a record of previous RestoreDates. The outfile would be retained for any necessary later audits. Your system audit journal can record save/restore details to supplement RestoreDates. Others might have plenty more to contribute. Tom

The RestoreDate attribute wouldn't be worth much if it could be changed to any desired value. It would possibly be irresponsible to describe in a public forum a method of restoring an object and obscuring its RestoreDate attribute. With that said and out of the way... There might be ways of doing what you need. E.g., it's potentially possible that a restore from SAVSTG might retain old RestoreDates -- I haven't done such a restore in the past ten years and didn't check. I sure wouldn't count on it. You might be able to (1) rename LIBA to LIBAprevious, then (2) RSTLIB LIBA for a test, then (3) delete LIBA and (4) rename the old library back. That kind of procedure obviously requires extra space, but objects within LIBA should look at the end pretty much exactly like they did at the beginning. Unfortunately, it's a pretty small part of an entire DR test. The basics of that thought might spark other more complete ideas. You might run a controlled DSPOBJD *ALL/*ALL to an outfile in order to create a record of previous RestoreDates. The outfile would be retained for any necessary later audits. Your system audit journal can record save/restore details to supplement RestoreDates. Others might have plenty more to contribute. Tom