If fetching the physical file record with rrn is ugly, how much uglier
is it to insert readp logic in the middle of a reade loop?
Using a read-only logical file as your main driver removes your record
locking issues and removes any record locking logic you have already
probably had to insert in the program.
Chaining out to the PF with the RRN and then issuing an update to the PF
where you are now issuing an update to the logical file are the only
logic changes required.
I am sure I am oversimplifying your programs and they are probably
monstrous, but adding logic to do reade(n) and then readp and reade
without the (n) in order to update the record seems to add more
monstrous (and inelegant), code on top of what already exists.
Paul Therrien
Orion South, Inc.
504-374-9551
800-437-7173
ptherrien@xxxxxxxxxxxxxxx
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Hockchai Lim
Sent: Friday, March 02, 2012 11:49 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Re-READ the current record
There is always a possibility. But the chance of it happen is very low
since each thread processes a different customer. My other option is to
put a Physical file that is key by RRN and chain back to it by RRN and
perform update on it. But this method also has it's own ugly problem.
If it is a brand new program, it wouldn't be so bad. But it is an
existing process and it is quite a massive process to deal with. If you
have dealt with Billing or Invoicing process before, you probably knows
that this type of process is not of those that you want to make a
mistake on.
"Brian Johnson" wrote in message
news:mailman.598.1330709340.14575.rpg400-l@xxxxxxxxxxxx...
Is it guaranteed that READP followed by READ will get you back to your
original record in all cases? I'm thinking of concurrent updates or
inserts that that place a different record after the record read by
READP. You have concurrent updates; are other billing threads
performing inserts? What about other non-billing processes that may be
updating the table in question?
--
Brian Johnson
brian.johnson.mn@xxxxxxxxx
--
This is the RPG programming on the IBM i / System i (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.
midrange.com
