Re: CHAIN or READ without lock

Thanks for the reply. My comments were very terse. I 100% agree with the below.
My first experience with record locking was on a S/3 (CCP) where if you tried to
get a
locked record the program instantly crashed, so we developed methods like using
unique update
numbers and/or checking the record prior to update.  I agree with John  'lock 
the
record
only just before the update' , that way you best exploit the AS400 default wait
time on locked
records. Proper design does not need a 'Read with Lock'.

John P Carr wrote:

> (See previous post below from Carl Pitcher first)
>
> "THE BLIND UPDATE "
>
> In addition,  you still have trouble if you do not ensure that the record
> that you originally got is the same image as the next time you
> access the record (unlocked) for update.
>
> Consider,   AP clerk puts vendor record up just to change the zip code.
> At that time the credit hold flag was "NO" for that vendor.
> Unbeknownst to the clerk while the record was up on their screen(Record is
> unlocked),  the Credit Manager updates that vendor sets the credit hold
> flag to "YES".    AP clerk presses enter and gets the changed record and
> updates
> the Zip Code,  but the Credit Hold flag was on the screen an the program
> does an UPDATE statement.
>
> Now the AP clerk inadvertently(unknowingly) just changed the credit hold
> flag back to "NO"  and the funny thing is that person isn't even authorized
> to update that field(via program logic).  And the AP clerk's name is on the
> record (maybe) as the last person updating the record.
>
> You must make sure the record you just re-accessed for update is the same as
> it was when you originally got the record and put it up on the screen.
>
> This is a very easy process using D/S's
>
> BTW, If you are going to COMMON,  come to Ron Harvey's and my session
> and we will give you the boiler plate code to do it.
>
> John Carr
> ---------------------------------------------
> I respectfully submit that if you're writing code for file updates & locking
> the records (especially in subfiles or file maintenance applications),
> you're building in alligators.  Consider a customer file maintenance program
> for example:  the operator keys in the customer number and displays the
> information for change, the phone rings and the record remains locked for
> the duration of the phone call (unless it's time to go to lunch) -
> meanwhile, the alligator waits to bite you in the ass because the batch job
> posting invoices is just sitting in the q waiting to update the customer
> balance in the locked record, which causes a program check, which gets
> cancelled by the system operator, which screws up your data.  Design your
> code so that you get the information without locking the record and only
> lock the record when you are ready to update it.

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---