× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Can't we all just code along?

Albert

----- Original Message -----
From: "Steve Landess" <sjl_abc@xxxxxxxxxxx>
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
Subject: Re: Program design to minimize record locks
Date: Thu, 19 Jul 2007 10:06:28 -0500


Booth - Finally, a good idea from you!

- sjl

----- Original Message -----
From: "Booth Martin" <booth@xxxxxxxxxxxx>
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
Sent: Thursday, July 19, 2007 9:14 AM
Subject: 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.



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





As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.