Re: CPF3812, but no sign of a lock

On 19 Jun 2013 15:18, James H. H. Lampert wrote:

We recently did an update of one of the customers of our CRM product.
This update involves automated downloading of, and restoration from,
a modular set of save files.

For some reason, we got CPF3812s on the restores for three of the
save files, even though a WRKOBJLCK showed no locks on them. Retrying
the restores caused them to restore cleanly.

Does anybody have any insights into what could have caused this?
Hidden jobs scanning newly downloaded save files for malware? Evil
spirits?

Locks are transient, so whatever caused a conflict in the past may since have gone away; thus what WRKOBJLCK showed or did not show, after the errors were received, is easily dismissed as immaterial. The fact that a retry of the failed operation succeeded is just more evidence that any conflicting lock(s) was no longer in effect... but nothing more is revealed about what locks might have been in effect during the failure.

While I am unsure of the possibility it might assist, the context of each CPF3812 was not given, nor were any prior messages given that might be related [nor their context either, if any exist].

Regardless, I suspect whatever the means to /download/ in conjunction with whatever /automated/ the restore activity are possibly in conflict due to failed assumptions about what, when, and how long, conflicting locks would be obtained and held spanning the conflicting activity. Although, not necessarily directly the fault of either phase of the coded /install/ process, the conflict may arise instead from something much like the posited "hidden jobs scanning newly..."

One very common origin for unexpected locks after a new object is created on the system, results from HA software that reacts to the T-CO entries in the audit journal. The locks from the HA could in theory be either or both object locks or locks effected by an open; however the actual locks is suspect, because IIRC ALCOBJ only supports locking *FILE objects of the database variety [redirecting the only supported device file, the DDM file, to the target system to obtain the lock]. If the download is into QTEMP and there is no MOVOBJ into another library [or the High Availability feature does not recognize a /new/ object moved], then the HA background\asynchronous tracking activity should not be the origin. For something like an FTP PUT [into other than QTEMP] the problem would normally be resolved by pre-create and then allocate with a sufficiently long wait time; but as noted, ALCOBJ is not very helpful with non-database *FILE objects, and I am unsure if a shared open and restore would get along.

While the SAVF has the ability to have a WAITFILE, the file if created by an interface like FTP might not have a value other than *IMMED [the shipped default for CRTSAVF], and even if there was a wait-time that is other than immediate timeout, the failing operation would need to have properly honored that wait. IIRC both FTP and DSPSAVF [so presumably its effective equivalent API] did not honor the wait. And I would not be surprised if RSTOBJ\RSTLIB implemented the same lock validation that gives rise to a CPF3812; again, without regard to the WAITFILE setting for what one might presume to be the /open/ to display\retrieve the content of the save file.