Can using PROCOPY and PROUTIL -C BUSY result in a corrupted target database?

PROCOPY runs as background session: nohup procopy <sourcedb> <targetdb> &
Verifying if PROCOPY has finished using: proutil <sourcedb> -C BUSY
The resulting target database is then corrupted when next accessed
Inconsistency between timestamps on the target database and bi result error 9213

Will PROUTIL BUSY option indicate when a PROCOPY has completed?

PROCOPY does not lock the source or target databases (no .lk file) so that when proutil -C BUSY is issued, the return message indicates that the database is not busy.  

Consequently, the "proutil -BUSY" operand does not cause the corruption.  It is just that the script incorrectly assumes that the database was not busy and could be accessed.  

When a new process makes a connection to the database before "procopy" was completed, it performed roll back recovery resulting in the bi file timestamps being out of sync with the (.db) master blocktimestamps.
 

Rather than running the proutil -C BUSY to monitor the completion of the PROCOPY operation, consider:

(A) Running a query on the PROCOPY process in a loop to determine when the process ends:

$   ps -ef | grep procopy

- or -

(B) Send the output to a file and then monitor "procopy.out" for "Copy complete (6722)" before accessing the database:

$   nohup procopy <source> <target> > procopy.out &

- or -

(C) Place the "procopy" in a shell script which creates a file to indicate a copy is in process, and then delete the file when the PROCOPY process is completed.