Re: CPF3812, but no sign of a lock

[CRPence <CRPbottle@xxxxxxxxx>]

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.