On 26 Apr 2012 13:40, David Gibbs wrote:
I'm getting a CPF4128 intermittently ... and *NOT* in the program
that's doing the CPYF.
A web search of CPF4128 CPYF will show many incidents, but most will
talk about that failure when another job accesses the FROMFILE, not the
The best I can tell is that the CPYF is locking the object in some
way and then other applications are getting errors when trying to
access the file in question.
An *EXCLRD would prevent any Open [with update capabilities]; i.e.
open for anything other than read-only would fail while a *EXCLRD was
held in another thread. The WAITFILE setting of the file [as set by
OVRDBF or CHGxF] is pertinent in such a scenario to minimize the impact
to the requester of an Open; e.g. OPNDBF OPTION(*ALL).
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.?
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2021 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
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.