Record locks (was In defense of the lowly MR)

Dean,

>In a message dated 97-06-06 13:24:39 EDT, you write:
>
>> UP files work very well for batch jobs, where by definition you can't lock
>> a 
>> record for a long time.  I'd never consider UP for interactive work.  I'd 
>> rather use UF with a CHAIN (no lock) for the "get" part of the app, then 
>> CHAIN (lock) for the "update" part.  Now, of course, we have the "record 
>> changed in the interim" problem to contend with....
>
>Of course, the AS/Set CASE tool provides a %IMC function that automatically
>locks the record if the Image hasn't changed since it was last read to allow
>update.  You can duplicate this by having an externally defined data
>structure (against the file) that you move the values into upon the initial
>(non-locking) read.  Then read the record with a lock and move the values
>into another data structure (again, based upon the file).  If the two data
>structures aren't equal, tell the user that "the record has been updated by
>another user" -- otherwise, update it.  This is a LOT easier in AS/Set, but
>can be replicated with RELATIVE ease if you're using a PC with an editor that
>allows cut and paste in SEU.  It would be even EASIER if you could move a
>record format name to a data structure....

That's certainly one way.  We've wrestled with the record lock/interim update 
problem for EVER!    There are several things that combine to make our
lives unpleasant:
1. Legacy databases are not normalised, which leads to
2. Multiple programs are needed to update the same file, which leads to
3. Record locks, or interim update errors.

Take a legacy customer master file for instance:
CUST#
NAME
ADDR
SALE01
SALE02
SALE03
CRDLIM

When you have an address change, you run an interactive program that lets the 
customer service rep change NAME and ADDR.  For credit limit changes,  you
run another interactive program that lets the credit manager change CRDLIM.
Several times a day, a batch program runs that can update any of the SALExx
fields.

If the address change program locks the record, then neither of the other 
programs
can update the record, so we have to avoid locking the record.

If the address change program reads the record and it's user goes for a cup of 
coffee,
then the credit manager reads the record and updates the credit limit, when the 
CSR
returns to her desk, the program will tell her that the "record was changed."  
The fact 
that absolutely nothing pertaining to HER job was changed only confuses her and
adds to turn-over.

So, instead of storing ALL the fields, we store only the fields that this 
program can
change.  That way, the credit people can update credit info and the customer 
service
can update their address info, and only when a conflict with a common field 
occurs
do we issue the "record previously updated" message.

Again, that's just one way... I'm sure there are others!

Thanks!

Buck Calabro
Commsoft
mcalabro@commsoft.net

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