Re: Program design to minimize record locks

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

--
---------------------------------
Booth Martin
http://www.Martinvt.com
---------------------------------

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.