RE: Record Lock message

[Buck Calabro <mcalabro@xxxxxxxxxxxx>]

James,
This is perhaps the most well-reasoned, rational note I've seen on this
topic.  Ever.
Your final comment (which I've quoted) is the textbook description of a true
client/server application.  The client does the data presentation and
requests that the server commit changes to the database.  To further refine
your concept of queuing update requests, may I suggest that we aren't really
trying to manage record updates, but field updates.

Many of the record overwrite conditions come from use of the RPG UPDAT
operation code.  This results in writing stale information (from THIS
program) over the top of recently updated fields (from THAT program.)  If
the customer address maintenance program would use EXCPT and only update
NAME, ADDR, CITY then it wouldn't clobber ARBAL.  Of course, when you have
two address maintenance programs working the same customer, you'd have a
problem.  But realistically, which of those updates is correct?

Husband and wife are simultaneously on the phone, requesting an address
change.  He says that they live on 25 Main St and she says that they live on
25 Main Ave.  Does the program blithely accept the last one in, or does it
detect that the address changed between the time the husband asked for the
record and the record was ready to update?  "I'm sorry sir, but someone else
just changed your address to 25 Main Ave - are you certain you live on Main
St?"  Sure makes you think about just how crowded NOT to make your display
screens, doesn't it?

Like I said, a very well-reasoned note.  Thanks for starting such a good
discussion!

Buck Calabro

> -----Original Message-----
> From: James W. Kilgore 
> Sent: Tuesday, June 29, 1999 2:27 AM
> To:   RPG400-L@midrange.com
> Subject:      Re: Record Lock message
> 
> 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
> 
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *