RE: CHAIN or READ without lock

[John P Carr <jpcarr@xxxxxxxxxxxx>]

(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
+---