Re: Suggested technique -- RPG400-L

Hi Carel.  

Actually, the code I am wiritng takes denial messages from a billing
file, and, after parsing the messages out of a human-readable report
(<-- the bulk of the code),  inserts them as memo record on the
account.  The code for users entering their memos throughout the day
is a vendor-supplied app, and I don't have the source for it. 
Furthermore, their code doesn't apply any such logic as I am
developing (with Alan's help ;-).  I wrote a terminal macro, that
continuously enters 'TEST' into the memo fields using their apps, and
running the macro on two screens using the same account number plops
the error on the screen, to make the user cry.  I just wanted to be
sure that my program doesn't hang while adding these messages, or else
I have to track which ones were written, possibly writing duplicates
on a re-run, etc.

I would consider what you are saying as valid, though, because the
user screen for entering memos acts just like a notepad, and the lines
wrap.  I would probably write the input program to first get all lines
from the user for the memo, then attempt to create a set of memo
records to handle all lines consecutively, and then go back and update
the lines.


On Mon, 31 Jan 2005 17:55:25 +0100, Carel Teijgeler
<coteijgeler@xxxxxxxxx> wrote:
> Tony,
> 
> One point that interests me: If two or more persons are adding a memo to one 
> account at the same time, this technique will mix their entries. Is that 
> acceptable? You may end up with very strange memos.
> 
> Having read the other replies I think a key based on accont# and line# 
> (sequence) is not sufficient to not mingle two or more memos enterd at almost 
> the same time.
> 
> I just cannot imagine it happening. Methinks, the record for that specific 
> account# should be locked.
> 
> But then perhaps< I misunderstand the situation.
> 
> Regards,
> Carel Teijgeler
> 
> *********** REPLY SEPARATOR  ***********
> 
> On 29-1-05 at 13:52 Tony Carolla wrote:
> 
> >Excellent!  That is exactly what I was looking for.  I wasn't sure if
> >the on-error operation could iter to the top of the loop.
> >
> >I never though of eliminating the chain, but it makes sense, and it
> >will be quicker, as long as most of the accounts have at least one
> >memo record.  And these are billing response records, so most of them
> >do.
> >
> >Thanks!
> >
> >
> >On Sat, 29 Jan 2005 11:18:01 -0500, Alan C <steelville@xxxxxxxxxxx> wrote:
> >> Hello Carel,
> >>
> >> >Tony,
> >> >
> >> >If the memo records are created in a seperate programme, I would use a
> >data area.
> >> >
> >> >
> >> The problem with the data area is that you would have to have a separate
> >> data area for each account number, if I understand Tony's situtation
> >> correctly.
> >>
> >> But I would use his own technique with a couple of changes:
> >>
> >> Instead of:
> >>
> >> - Chain using account#
> >> - if no matches, sequence=1
> >> - if %Found, SETGT using account#, READP, then add one to the sequnece
> >> number.
> >>
> >> Do this, eliminating the CHAIN:
> >>
> >> - Use SETGT using account#   ( setgt(e) account# filename )
> >> - Do a READPE using account#  ( readpe(e) account# filename )
> >> - If not %Found, sequence = 1
> >> - else sequence = sequence + 1
> >>
> >> But add the loop to handle the duplicate key message:
> >>
> >> - Dou   I_say_leave
> >> - Monitor
> >> - SETGT using account#   ( setgt(e) account# filename )
> >> - READPE using account#  ( readpe(e) account# filename )
> >> - If not %Found, sequence = 1
> >> -     else sequence = sequence + 1
> >> - Endif
> >> - Write MemoRecord
> >> - On-Error  DupKeyStsCode  (Or *FILE or ?)
> >> -     Iter
> >> - End-Mon
> >> - I_say_leave = *ON
> >> - Enddo
> >>
> >> There are some brilliant programmers here, however, who advocate
> >> avoiding use of the "iter" and "leave" op-codes. I find it hard to avoid
> >> using them myself, but am still open on that issue.
> >>
> >> Hope that helps.
> >>
> >> - Alan
> >>
> >> --
> >> 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.
> >>
> >>
> >
> >
> >--
> >"Enter any 11-digit prime number to continue..."
> >--
> >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.
> 
> 


-- 
"Enter any 11-digit prime number to continue..."