Re: Record Lock message

James,

I'm overwhelmed with the locking strategies you described. It's simply
wonderful.
I have chosen the 1st one to do.
Let's see how much I succeed.

Thanks very much for such a valuable answer.

Rajeev.





"James W. Kilgore" <qappdsn@ibm.net> on 06/28/99 11:26:59 PM

Please respond to RPG400-L@midrange.com












Subject:  Re: Record Lock message




Rajeev,

Booth brought up a popular method of handling record locks. IMHO, this is not
the type of thing that one should "patch" into an application suite but one
should design in.  Just like security.

Although this method does serve the immediate purpose, it's (again) one of
those "it depends" scenarios.  What function is being performed that created
the locked condition?  Are you managing a change to a cable TV subscription
where the odds of two people from the same house are going to call in, from
two separate phone lines, to request a change of service at the same time? Or
are you receiving calls from 5000 people per hour trying to get seats at the
third base line for the 7th game of the World Series?

The different methods I've seen promoted are:

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)

I'm sure that within the members of this list we'll find a few that favor each
solution.  Each have their benefit and cost. (Solutions that is, not the
members, well actually....:)

Just off the top of my head:

1) Lock the record and keep it locked. Make the others wait/time out.  This is
real simple to program.  The same, or other programs that update the file can
test the error return code for a locked condition and either skip the record
(for batch) or give feedback to an interactive request.  This works well for
the cable TV subscriber where the odds of two users trying to make a change to
the customers service file at the same time is very low.  The draw back is
that once a customer account is called up for change, it's locked even if the
user goes to lunch, or goes home. One must incorporate time-out mechanisms and
queue skipped updates.  This can be (maybe) solved where the information is
split into multiple physical files and the customer record is locked, but the
last billed information file is not locked.  Again, it depends.  It's an
application design consideration.  Will lock up DFU/DBU/etc. outside update
attempts without "friendly" feedback.

2) Don't lock the record, but write the key field to a control file.  This was
real popular with IBM application products.  IBM got out of the application
business.  This solution keeps an in-house person busy and a contractor
profitable <G>.  Managing the control file is analogous to juggling cats. I
think I'll let this one drop rather than shift gears. Again, falls on it's
face if DFU/DBU/etc. outside updates are performed.

3) Read without locking then compare "before" images to allow requested
change. (Booth's well supported suggestion).  This works very well when an
application must coexist with the possibility of outside (DFU/DBU/etc.)
changes to a record.  (And if it -can- occur, IMO it -will- occur) If the
scenario is that the user is on the phone to a customer and merrily going on
their way typing changes, then presses ENTER, then gets a "prior data has
changed/request rejected" message, what are you going to do about it?  Lose
all of the changed data? Highlight what has actually changed? Accept the
change if the new data has nothing to do with whatever else changed? Test for
corequisite information? Make the user look stupid in front of the customer?
Have the user mutter "stupid computer" to the customer to save face?  (BTW,
IMHO, computers are not stupid, they just are. Designers are lazy or keepers
of the cash are cheap. But that's another thread)

For managing record locks, one is really managing record updates.  I suppose
that one could design their batch/interactive programs such that
updates/additions are not performed, but are merely requests and queued, and
requests could test the queue for prior, unapplied, requests.  And who would
of thought that a S/3 slam an' bam would grow up some day to use 30+ year old
mainframe techniques to achieve "robustness"? =;-o

James (and you thought you were getting off easy) Kilgore
email@James-W-Kilgore.com



boothm@ibm.net wrote:

> Rajeev, what does "using a record" mean?  The record needs to only be
> locked and unavailable when it is being changed.  Ordinary READs of the
> record can have an (N) to indicate "Not locked" and you will have no
> problems with locking records, etc.
>
> For the other problem, when a record is being changed, do all the validity
> checking and getting ready to update while the record is still unlocked.
> Save all the original field information in a data structure or something.
> Then when you are ready to do the update, read the record again, (without
> the (N) ) and compare the data with the original.  If the data is the
> same, then you are good to go.  Make your change and continue.  If the
> data just read is different than the data read a few minutes ago, then
> another user has already changed the record. Send a message then, saying
> the record has already been changed.
>
> If you use this sort of solution your records will be locked for less than
> a second even if a user has a record on the screen and leaves for lunch.
>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *






* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *