Re: Program design to minimize record locks

[Alan Shore <AlanShore@xxxxxxxx>]

Morning Pete
if my memory is correct (not a sure thing now-a-days) but I'm sure there
was a similar discussion not too long ago.
You may want to check the archives.



Alan Shore

NBTY, Inc
(631) 244-2000 ext. 5019
AShore@xxxxxxxx
"If you're going through Hell, keep going" - Winston Churchill


                                                                       
             Pete Helgren                                              
             <Pete@xxxxxxxxxx>                                         
             Sent by:                                                   To
             rpg400-l-bounces@         RPG programming on the AS400 /  
             midrange.com              iSeries <rpg400-l@xxxxxxxxxxxx> 
                                                                        cc
                                                                       
             07/19/2007 09:58                                      Subject
             AM                        Program design to minimize record
                                       locks                           
                                                                       
             Please respond to                                         
              RPG programming                                          
              on the AS400 /                                           
                  iSeries                                              
             <rpg400-l@midrang                                         
                  e.com>                                               
                                                                       
                                                                       




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
--
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.