×
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 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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.