×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 12-Jul-2011 19:00 , Charles Wilt wrote:
The following command was issued:
RSTLIB SAVLIB(HLTHPRDFIL PRCPRDFIL CRMSARFIL) DEV(TAP3576)
VOL(I00040) OPTION(*NEW) MBROPT(*ALL) OMITOBJ((*ALL *JRNRCV))
However, existing files were replaced with the saved version from
the tape.
The way I read the help for the OPTION parameter, I wasn't expecting
that.
Option (OPTION) - Help
*NEW
Only the objects in the saved library that do not
exist in the current version of the system library are
added to the library. Only objects not known to the
system library are restored; known objects are not
restored. This option restores objects that were
deleted after they were saved or that are new to this
library. If any saved objects have a version already
in the system library, they are not restored, and an
informational message is sent for each one, but the
restore operation continues.
The OPTION(*NEW) indeed should preclude a restore of a *FILE by the
same name, just as with any other object type; i.e. if the object on the
media shares the same name and type as an object that already exists in
the restore-to library name, then a message should be issued [and if
OUTPUT() specified, then logged there too] suggesting that the object
was not restored because the object already exists.
Was the effect of replaced\overwritten a conclusion based on the lack
of the "already exists" messages, the existence of messages\output
suggesting that the objects were restored\overwritten, or by review of
the object creation date, owner, restore date, and\or data?
Had there been a prior restore of these libraries which had either
failed or otherwise been interrupted? If so, the partially restored
object were actually "logically damaged", and database *FILE recovery
processing may have actually done the favor of destroying\deleting the
pending objects and recovery to allow the proper restore. In the past
no such auto-recovery was supported for restore, such that a DLTLIB
would have been expected as user-invoked corrective, but the enhancement
for restoring logical dependencies may have had some impact on that
original design; though with not too much thinking, I think such a
change probably would be a defect.
What am I missing?
If the results are as described, since there should be no other
parameter specification which should legitimately override that behavior
[that I am aware of or any I could imagine], then apparently what is
missing is a PTF [hopefully for an APAR with the HIPer designation].
Regards, Chuck
midrange.com
