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

[CRPence <crp@xxxxxxxxxxxxxxxxxxxx>]

  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