Program design to minimize record locks

I have a change I need to make to a program that someone else had written. The program logic for data I/O is in a /Copy member so that all programs using the logic are affected by a current "design flaw" in the program which READs the record and locks it until the screen is exited and the record is updated. The record lock causes problems elsewhere.

So, without making too many changes and breaking something, I figure I should be able to:

1. READ the record (with no lock)
2. Present the data to the screen
3. Edit the data as usual
4. READ the record again with lock for update
5. Update the record releasing the lock.

This is standard stuff, but I think I need a "intermediate" storage step to hold the initially read record, yes? All of the RPG programs I have had experience with in the past have "direct" read/write IO with file record fields mapping to screen data fields using identical names. In this revision, I think I can't do that since the second read of data would overlay existing fields with the same name. So, I think I need to use a data structure to temporarily hold the original data while it is edited and verified.

So, what is the simplest approach to reading the data file record, moving it into a DS, and then moving it out of the DS and back into the data file after being re-read? And yes, I know that I'd have to check to make sure the record hadn't been updated during the time it was originally read and later updated. I poked around for some examples last night and couldn't find anything I could use (immediately). I'd like to avoid having to go back to each program that uses this /Copy member to make changes. I'd like to only change the /Copy member if possible.

Am I making any sense? Ideas?

Thanks,

Pete