Mark, thanks for your message. You raise some very interesting and (most
likely) very relevant comments. Let's go into a few details.

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

To my knowledge, no. I did not do it myself, because I am not officially in
charge of the system which got the SA. I was just helping a customer out of
some trouble. I do not know if the system administrator did it. If he did,
it would have been a call to Orbit France.

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 scenario looks totally identical to what I saw in my dumps. Seems we
have a dupe.

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.

Shouldn't BACKUPPL simply be SETCRITICAL during that critical code path (my
assumption being that this code path is reasonably short), in order to
avoid being interrupted ? Oh, well, just my $.02.

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).

If the scenario you described above is really what happens (and I strongly
believe it is), then there is no need to purge the whole group, since only
links at the file level, not at the group or directory levels are involved
(my understanding). Besides, I did not look for the characteristics of
/HPSPOOL/BACKUPPL group, capabilities, access matrix, and so forth. Just
had the files purged off.

Regards,


M.

Best regards,

Christian Lheureux
Head of Systems and Networks Department
APPIC R.H.
HPConnect Systems Integrator
HP3000 Expert