Re: Alternative to CPYF that doesn't apply a lock

I am not sure how changing data eliminates an RPG program, especially given CPYF was referred to originally; i.e. CPYF can not transition the data whereas a HLL program can. Regardless the solution to the concern fits nicely with SQL [to generate '002' records from '001' records]:
INSERT INTO ToFile SELECT '002',glf2,glf3,...,glfn FROM FromFile

Regarding the open failure, the wait for access is controlled by the WAITFILE parameter. The old default was WAITFILE(*IMMED), but the default was changed to WAITFILE(30) to be /more appropriate/ ; if the file was created several releases ago, CHGPF ToFile WAITFILE(30) would enable the applications to await the ability to obtain the lock to access the file. Also, the MBROPT(*REPLACE) versus MBROPT(*ADD) probably come into play. The former likely holds the lock since the clear, such that a CLRPFM before CPYF MBROPT(*ADD) would also enable the applications to await the ability to obtain the lock to access the file. However then the question becomes, was the timing of significance, such that the application should not have seen the partial insert after clear; i.e. perhaps the lock is desirable. Finally if the application opening the file being held with the conflicting lock wants to wait, and may need to wait longer than thirty seconds, that application can use the OVRDBF FILE(ToFile) TOFILE(*FILE) WAITFILE(120) OVRSCOPE(as_rqd) to have a run-time override to the desired wait time for open.

Regards, Chuck