>I am pretty sure I did this by restoring, using SPXTAPE, the NSS twice.
>
>My question or assumption is that I thought, when a duplicate entry is
>restored, it would flagged the existing
>
>one as purged/deleted/removable (what ever the correct term is).=20
>
>Could someone explain this?
By default, SPXTAPE LOAD will load an NSS that may duplicate one that
is already active on your system. SPXTAPE will load the NSS from tape
with the same class that it was SPXTAPE DUMPed with. SPXTAPE was
intentionally designed to operate this way; we didn't want the code to
decide for you which of the 2 NSSes you really want to keep.
There is a NODUP operand that you can use to prevent SPXTAPE from loading
a file from tape the duplicates an existing file:
NODUP
prevents the loading of any file that would duplicate a file that already
exists on the target spooling system queue. For additional information,
see usage note 4.
Usage Note 4:
4. When using the NODUP operand, the definition of "duplicate" depends on
the type of file.
For standard spool files and system trace files, "duplicate" means that
all the file attributes of the file on the tape are identical to a file
on the queue. This includes the time stamp for when the file was
opened. An identical time stamp indicates that they are identical
files. (If some files on the system have been imported from other
systems, it is possible that files could have been created on both
systems at exactly the same microsecond with all the same file
attributes, but contain different data. However, this is not very
probable.)
For system data files other than system trace files, "duplicate" means
that the file name, file type, and class of the file on the tape are
identical to the file on the queue. In addition, for named saved system
and saved segment files, class A (active) and class R (restricted)
files of the same file name and file type are considered duplicate
because they cannot exist on the system at the same time.
A file that is found to be a duplicate is identified in the resulting
volume log with DUP_FILE in the SEG_STAT field. The FILE field of this
entry in the log contains the file ID of the file already on the
system. If the file on the system is moved to a different queue or user
ID, or its file attributes are changed (for example, its spool class),
the file is no longer identified as a duplicate.
The NODUP operand helps you recover if a system failure occurs while
you are loading files from tape. If you add the NODUP operand to your
selection criteria and reprocess all the tapes that have already been
processed, all the files that loaded correctly before the system
failure are skipped. However, even with NODUP specified, you may still
receive duplicate files if you are loading the same file concurrently
from more than one tape.
Keep in mind when using the NODUP operand that as the number of files
in the queue where the files are being loaded increases, the amount of
processing required to load the files from the tape increases
dramatically. Each file to be loaded is compared to every file in the
queue. For example, if the queue contains 1000 files and 1000 files are
to be loaded, the result is over one million comparisons.
The consequence of loading duplicate files is more serious for system
data files than for standard spool files. If the NODUP operand is not
used when loading system data files (or all files) from a tape for
which no dump log is available, you should check to make sure that
duplicate files were not loaded. If this happens, check the files to
determine which should be kept and purge the unnecessary files.
John Franciscovich
z/VM Development
