Re: SAVRSTOBJ QUESTION

I noticed that v7r1 [IBM i 7.1] has added a new special value, a Single Value, to the ALWOBJDIF parameter on both RSTOBJ and SAVRSTOBJ; albeit without any change flags, even though the text does not exist in the v6r1 docs. :-( Apparently this new value is intended to ameliorate having to specify each of the desirable special values [*AUTL, *FILELVL, *OWNER, *PGP] separately, when the only aim is to avoid the database from renaming the data file and\or members to avoid overlaying existing data:

*COMPATIBLE
All of the differences listed above are allowed on the restore operation. See the description of each individual value to determine how differences are handled. This value allows differences that are compatible with existing database files. This value is usually preferable to the value *ALL which also allows differences that are not compatible with existing database files.

The above text [albeit incorrectly stating "above" where "below" is meant contextually within the help text and InfoCenter] can be found in each of these two command help\docs:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/cl/rstobj.htm
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/cl/savrstobj.htm

Regards, Chuck

On 03 May 2013 08:15, CRPence wrote:

On 03 May 2013 07:46, fbocch2595@xxxxxxx wrote:

I'm using SAVRSTOBJ to sav from 1 lib on one iSeries to a different
lib name on another iSeries and I'm trying to stop the 0001's from
generating on the target system. Is that possible? I'm saving
ACCPTH's. What's odd to me is that every time I run SAVRSTOBJ on
many libs there are always different files created with the 0001
suffix. The 0001's have text showing "Old name C01CMTXP in MYLIB
owned by". Could they be getting created due to authority
mismatches? How do you avoid the 0001 issue?

Note that beyond just the external object type *FILE, of the
database variety, there may be database *members* which also have
that renaming which have gone unnoticed. Even possibly effecting
more members than the MAXMBRS() limit for the file, because the
restore allows the new member to restore regardless of the limit,
when the outcome is due to its renaming activity.

Stop using ALWOBJDIF(*ALL) and the issue will not occur. Depending
upon how one /stops/ doing that, the effects may or may not be
desirable.

For any specific /differences/ to be ignore, explicitly list each;
e.g. *FILELVL. The database protects the existing data from
accidental restore-over by renaming the existing member or file,
*only* when the special value of *ALL is specified on the Allow
Object Difference parameter.