Re: RSTLIB OPTION(*NEW) overwrote existing files

On 12-Jul-2011 19:45 , Evan Harris wrote:

I've always been a little mystified by this command and the
relationship between the OPTION parameter and the MBROPT parameter.
Re-reading the help after seeing your email suggests that the OPTION
object operates at the Object level while the MBROPT operates at the
File Level.

Presumably OPTION allows the restore operation to determine whether
to restore the object or not. Subsequently, the MBROPT option is
checked to see whether or not to restore the contents of the files.
<<SNIP>>

Indeed OPTION() applies to [effectively] the external object types, and MBROPT() is specific to the member object(s) [*MEM internal object type] of the database *FILE object(s) that may exist on the media. When OPTION(*NEW) is specified, the default value of MBROPT(*MATCH) was in the past not allowed because that option requires the *FILE object of that name exists in the restore-to library with the same [matching] member list; i.e. the specifications were considered mutually exclusive, since restoring only new files precludes an existing *FILE with a matching member list. I see the docs in 7.1 seem to suggest that restriction is no longer the case.? The only other options available are *ALL, *NEW, and *OLD. As with *MATCH, each of *NEW and *OLD imply the effective requirement to have an existing database *FILE with that name in the restore-to library, leaving the special value of *ALL as an obvious choice; as to requiring an existing file, for the member option *OLD... obviously, and *NEW... arguably.

On both RSTLIB and RSTOBJ exist the additional granularity of member restore via FILEMBR(). So although the member option is restricted to [effectively or actually] the special value *ALL when restoring using the option to restore only *NEW [file] objects, the member names being restored can be limited by specifications on the file members parameter.

Regards, Chuck