Re: CPYF lock?

On 27 Apr 2012 12:23, David Gibbs wrote:

On 4/26/2012 5:03 PM, CRPence wrote:

The CPYF utility has some bit of "optimizer" logic whereby one
means of copy is chosen over another. One part of the logic, at
least for the FromFile, is whether there are any locks on the data;
i.e. no data locks follows one path, any data locks [beyond its
own] and another path is followed. If no locks, the CPYF escalates
its locks [beyond just *SHRRD] to use a more aggressive approach to
effect the copy data activity. Similar logic may exist for the
TOFILE.?

Is there any way to defeat that logic?

Do not use CPYF :-) Use a custom program, one that could even be somewhat generic like CPYF, probably using SQL INSERT INTO ... SELECT FROM instead of native\RLA. Since CPYF can not participate in isolation, that utility is already often not preferable for interacting within work, whereby another job might be affected by its locking.

I am mostly familiar with the FROMFILE locking per QDBFFCPY, so I am going from more intuition than actual recollection, but if CPY will be used then presumably...

Have another thread allocate the data, or even possibly the current thread allocate the data; e.g. OPNDBF TgtLib/TgtFile *INP MGR(TgtMbr) or OPNDBF DepLFlib/DepLFfile *INP MBR(DepLFmbr). That is, the expectation that the CPYF concludes the target data can not be locked exclusive. If the decision is via actual allocation versus asking if the dataspace has other locks, the alternate thread may be required. Depending on the method CPYF uses to detect not-in-use, the ALCOBJ versus OPNDBF may be sufficient instead.

Remove or disable logical access paths over the target before the copy. That is, either RMVM of the LFM or CHGLF to modify the maintenance (MAINT) of the target file access paths to *OPN or *REBLD before the copy. Having no accpth maintenance decisions, the CPYF will not consider that type of optimization that would require the escalated locking.

This particular problem I'm working on is REALLY tough ... as it's a
matter of timing and I haven't been able to actually reproduce it in
the lab.

Given a known-to-be occasionally failing request, and the details of the target file and the relations that have the target member as a based-on member, I might be able to have a better idea. My access to a system does not allow me much capability neither for storage nor authority, so I can not do any legitimate tests.

Regards, Chuck