Re: Record Lock message

["Dan Bale" <dbale@xxxxxxxxxxx>]

James,

Very well put!  The least painful of these, IMHO, is #1.  Way too many things
can go wrong for #2 to work reliably.  And ditto your comments on #3, "What'cha
gonna do if there _was_ a change?".

#1 works best when a user receives an informative message that a record has been
locked by another user.  When I last coded for this, I created a generic window
/ routine that allowed the locked-out user to cancel or retry.  Another
important point that I find a lot of experienced coders forget is that IBM gave
us the no-lock extender on input operations for update files (as was mentioned
previously).  I see a lot of examples where the same update file is used in a
read loop to build a subfile list, but without specifying the no-lock extender

>>1) Lock the record upon first access and program (via error) for any other
attempts.  Let OS/400 and user education handle it.
2) Don't lock the record, but manage it yourself through a control file.
3) Don't lock the record, but test for outside change before accepting the
current request (Booth's suggestion)<<





* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *