× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks Chuck.

Just curious, what if the file being updated is a logical view with only 10% of the total fields in the record. In that case, one would have to work with the PF just in case one of the non-visible fields was changed by another user?

Do shops take it to that level generally?

Thanks!


-----Original Message-----
From: COBOL400-L [mailto:cobol400-l-bounces@xxxxxxxxxxxx] On Behalf Of Chuck Landress
Sent: Friday, August 05, 2016 12:45 PM
To: cobol400-l@xxxxxxxxxxxx
Subject: Re: [COBOL400-L] COBOL400-L Digest, User Record Updates And Locking

Actually the procedure you describe is, in my opinion, the best way. You
avoid locking the record if the user has it on their screen for a long time
and you only update if a change has been made.

I worked on a system that read with no lock and then updated (COBOL can do
that). The number of inadvertent overwritten data changes was impressive.

​The system I work on currently locks records even on inquiries causing a
lot of system errors due to record locks. That said, we rarely have data
inadvertently overwritten. It sure is difficult to get the users to exit
screens before going to lunch.



--
Chuck Landress, PMP
678-469-2326

"Resistance is futile, you will be assimilated. We are the Bored"
-Unknown

On Fri, Aug 5, 2016 at 1:00 PM, <cobol400-l-request@xxxxxxxxxxxx> wrote:

Send COBOL400-L mailing list submissions to
cobol400-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/cobol400-l
or, via email, send a message with subject or body 'help' to
cobol400-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
cobol400-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of COBOL400-L digest..."


Today's Topics:

1. user record updates via a cobol program: how to deal with
record locks and data changes (Stone, Joel)


----------------------------------------------------------------------

message: 1
date: Fri, 5 Aug 2016 16:45:29 +0000
from: "Stone, Joel" <Joel.Stone@xxxxxxxxxx>
subject: [COBOL400-L] user record updates via a cobol program: how to
deal with record locks and data changes

What is a good way to handle record locks when a user changes a DB record
via a cobol pgm?

Also how to avoid one user's changes from overlaying another user's recent
changes.

Is the best way to read with no lock, wait until user enters data into
screen, then re-read with a record lock?

And only update the record if there were no changes between the two reads
by comparing the entire record strings?


Any other methods that work well?

Maybe read the journal to ensure no one else has changed that particular
RRN during the users input?

Thanks!

Joel



------------------------------

Subject: Digest Footer

--
This is the COBOL Programming on the IBM i (AS/400 and iSeries)
(COBOL400-L) digest list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.



------------------------------

End of COBOL400-L Digest, Vol 14, Issue 20
******************************************


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.