>As a workaround, I had my customer purge all files in /HPSPOOL/BACKUPPL,
>re-run the restore, and everything worked OK.

>Anyone got hints ? Ideas ? Trails to pursue for further dump analysis ?

I don't mean this to be offensive, but did you try calling us with the
question?

We have discovered a scenario whereby the filesystem thinks that an
unlinked spoolfile is actually linked, and when we purge it in
preparation for restoring another file of the same name, the FS
causes the system abort. Our problem number is SR4022 and we
are adding code to the product to detect this scenario and
clean up the filelabel before purging the file.

This is a corner case that only appears to happen when for some
reason, a prior restore/link to the spooler of a spoolfile failed.

We restore and temporarily stage the spoolfile into the
/HPSPOOL/BACKUPPL group and AIFSPFLINK is invoked to link the
spoolfile to the spooler. This causes another copy of the file
to be made into the /HPSPOOL/OUT group. At that point, the file
in /HPSPOOL/BACKUPPL is supposed to be purged. Sounds like this
got interrupted somehow and a subsequent restore of that file
caused the SA.

You're workaround is the correct workaround ... purge all files
in /HPSPOOL/BACKUPPL before doing the restore. (Note that the
safest way is to purge and rebuild the group, not do a purge
of @.BACKUPPL.HPSPOOL).

Regards,


M.