Re: Program design to minimize record locks

[Booth Martin <booth@xxxxxxxxxxxx>]

What has worked for me in the past is to define a data structure with 
the EXTNAME() keyword and then two fields LIKE() the data structure.
Something like this:

D  FileNameDS      ds        extname(Filename)
D  OrigData        s         like(FileNameDS)
D  NewData         s         like(FileNameDS)

Then read(n) the data, move it into OrigData and present the screen.
Do your stuff.
Then if ready to write, move FileNameDS into NewData and read(locking) 
again.
if FileNameDS <> OrigData the record has been changed elsewhere; 
otherwise, move NewData into FileNameDS and update the data file.

I am not sure how is the easiest way for you to get the definion specs 
into each program however. 

Pete Helgren wrote:
> 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
>