Re: SAVRSTOBJ QUESTION

Hi Chuck,

You said "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. "

Is that true when MAXMBRS is *NOMAX? Or does an error occur in that situation?

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx>
pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx>/


On 5/3/2013 8:15 AM, 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.