Re: CPYF lock?

On 26 Apr 2012 15:03, CRPence wrote:

On 26 Apr 2012 13:40, David Gibbs wrote:

If, however, the file is already open in another application ... no
error occurs when I copy records using CPYF.

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

I think beyond the COMPRESS(*NO) previously mentioned, any other cases for which the CPYF thinks [by its optimization choices] that invalidation of the access paths on the TOFILE.TOMBR before copy is beneficial to the performance of the request, would qualify for an escalation of its locks on the [member of the] TOFILE. For example, when the amount of data to be copied would be "large" and\or the number of access paths over the target dataspace that require [*IMMED] maintenance is "large"; relative to what numbers, in either case, I have no clue.

FWiW I am not sure if the optimization algorithm takes into account the number of locks held by other threads versus its own. Thus by preceding the request to CPYF FROMFILE(XLIB/XFILE) FROMMBR(XMBR) with a [or two effective] requests to ALCOBJ ((XLIB/XFILE *FILE *SHRRD XMBR)), that may cause the CPYF to think the data is in-use and never even consider|traverse the code path that invalidates the access paths.

Regards, Chuck