×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
midrange.com
