|
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. Re: COBOL400-L Digest, User Record Updates And Locking
(Chuck Landress)
2. Re: user record updates via a cobol program: how to deal
with record locks and data changes (Mark S Waterbury)
3. Re: COBOL400-L Digest, User Record Updates And Locking
(Stone, Joel)
4. Re: user record updates via a cobol program: how to deal
with record locks and data changes (Jon Paris)
5. Re: user record updates via a cobol program: how to deal
with record locks and data changes (Jon Paris)
----------------------------------------------------------------------
message: 1
date: Fri, 5 Aug 2016 13:44:34 -0400
from: Chuck Landress <clandress@xxxxxxxxxxx>
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 torecent
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
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
******************************************
------------------------------
message: 2
date: Fri, 5 Aug 2016 15:03:39 -0400
from: Mark S Waterbury <mark.s.waterbury@xxxxxxxxxxxxx>
subject: Re: [COBOL400-L] user record updates via a cobol program: how
to deal with record locks and data changes
Joel:
*
*Do a google search for "os/400 avoiding record locks in cobol"
(without quotes) and you should find some good info.
Also, a google search for "os/400 lock-free r ecord i/o in rpg" will
give you some good web pages... even though talking about RPG, many of
the same techniques can be used in COBOL.
Here are a few ideas for how you can avoid having to hold record
locks for long periods of time in your interactive applications:
_METHOD A -- checksums or hash code_
1. when you first read the record, (with no lock), compute a checksum
or "hash" of the contents of the entire record buffer.
2. present the data on-screen for the user to (possibly) update.
3. when the user has updated some fields, re-read the original
database record again, with record lock this time, into another
buffer and re-compute the check-sum or hash code. If the hash or
checksum is still t he same then no one else has updated the record
in the meantime, so it is now "safe" to update that record with
the changes made by the user. (The update will release the record
lock automatically.)
4. if the check-sum or hash does not "match" you need to release the
record lock and inform the user that another person has updtaed
the same record -- present the (newly updated) data again, and ask
the user to re-enter the changes. (... lather, rinse, repeat ...
as needed until the update is successful or the user presses
F12=Cancel ...)
_METHOD B -- a similar but simpler approach_
A simpler, low-cost variation on the above, relies on adding a single
"UPDATEID" field to each file you want to update "lock-free" -- it can
be a binary integer or a packed numeric field, if binary, you can use a
2-byte or 4-byte integer, or packed with at least 5 or more digits.
Proceed as follows:
* whenever a record is first added to the file, initialize this
UPDATEID field to zero. (Could be handled by an INSERT trigger)
* whenever any application program updates any record in this file,
you must ensure that the UPDATEID value is always incremented by 1
The algorithm for updating is similar to the above, with these
changes. Instead of computing a checksum, you just remember
theUPDATEID value ... and compare it , as follows:
1. when you first read the record, (with no lock), save the UPDATEID
value for use later.
2. present the data on-screen for the user to possibly update.
3. when the user has updated some fields, re-read the original record
again, with a record lock this time, into another buffer and If the
UPDATEID is still t he same as the saved value, then no one else
has updated the record in the meantime, so it is now "safe" to
update that record with the changes made by the user. Increment the
value of UPDATEID in the record buffer about to be updated (This
update I/O will also release the record lock automatically.) (An
UPDATE trigger could handle incrementing the UPDATEID field.)
4. if the UPDATEID does not "match" you need to release the record lock
and inform the user, that the record has been updated by someone
else, and present the (newly updated) data again, and ask the user
to re-enter any changes. (... lather, rinse, repeat ... as needed
until the update is successful or the user presses F12=Cancel ...)
The main "down side" to METHOD B is that _everyone must follow these
rules_ to ensure that the UPDATEID is always incremented whenever a
record is updated. (The "increment" logic could be put in a trigger to
make that part easier.) But, you must still add logic in your
applications to save the UPDATEID on the first READ and compare it
again, just prior to any update ... -- if anyone forgets orignores
these rules, your users will suffer "lost changes" like what happens if
you use no record locking at all.
Hope that helps,
Mark S.Waterbury
> On 8/5/2016 12:45 PM, Stone, Joel wrote:
What is a good way to handle record locks when a user changes a DBrecord via a cobol pgm?
recent changes.
Also how to avoid one user's changes from overlaying another user's
screen, then re-read with a record lock?
Is the best way to read with no lock, wait until user enters data into
reads by comparing the entire record strings?
And only update the record if there were no changes between the two
RRN during the users input?
Any other methods that work well?
Maybe read the journal to ensure no one else has changed that particular
Thanks!
Joel
> On 8/5/2016 12:45 PM, Stone, Joel wrote:
What is a good way to handle record locks when a user changes a DBrecord via a cobol pgm?
recent changes.
Also how to avoid one user's changes from overlaying another user's
screen, then re-read with a record lock?
Is the best way to read with no lock, wait until user enters data into
reads by comparing the entire record strings?
And only update the record if there were no changes between the two
RRN during the users input?
Any other methods that work well?
Maybe read the journal to ensure no one else has changed that particular
Thanks!
Joel
------------------------------
message: 3
date: Fri, 5 Aug 2016 19:58:15 +0000
from: "Stone, Joel" <Joel.Stone@xxxxxxxxxx>
subject: Re: [COBOL400-L] COBOL400-L Digest, User Record Updates And
Locking
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 torecent
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
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
******************************************
This is the COBOL Programming on the IBM i (AS/400 and iSeries)
(COBOL400-L) mailing 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.
------------------------------
message: 4
date: Fri, 5 Aug 2016 16:02:44 -0400
from: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
subject: Re: [COBOL400-L] user record updates via a cobol program: how
to deal with record locks and data changes
I use the exact same technique I do in RPG.
Read the record with no lock and keep a copy of the record image.
Present the record for update
Input the user updates.
Re-read the record with lock and compare the record image with the stored
one.
If they match go ahead and do the update. If not ? error/retry/whatever of
your choice.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
On Aug 5, 2016, at 12:45 PM, Stone, Joel <Joel.Stone@xxxxxxxxxx> wrote:record via a cobol pgm?
What is a good way to handle record locks when a user changes a DB
recent changes.
Also how to avoid one user's changes from overlaying another user's
screen, then re-read with a record lock?
Is the best way to read with no lock, wait until user enters data into
reads by comparing the entire record strings?
And only update the record if there were no changes between the two
RRN during the users input?
Any other methods that work well?
Maybe read the journal to ensure no one else has changed that particular
(COBOL400-L) mailing list
Thanks!
Joel
--
This is the COBOL Programming on the IBM i (AS/400 and iSeries)
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.
------------------------------
message: 5
date: Fri, 5 Aug 2016 16:03:36 -0400
from: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
subject: Re: [COBOL400-L] user record updates via a cobol program: how
to deal with record locks and data changes
Why bother with a hash Mark when you can just compare the record images?
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
On Aug 5, 2016, at 3:03 PM, Mark S Waterbury <mark.s.waterbury@xxxxxxxxxxxxx> wrote:
(without quotes) and you should find some good info.
Joel:
*
*Do a google search for "os/400 avoiding record locks in cobol"
give you some good web pages... even though talking about RPG, many of
Also, a google search for "os/400 lock-free r ecord i/o in rpg" will
the same techniques can be used in COBOL.
locks for long periods of time in your interactive applications:
Here are a few ideas for how you can avoid having to hold record
record lock and inform the user that another person has updtaed the
_METHOD A -- checksums or hash code_
1. when you first read the record, (with no lock), compute a checksum
or "hash" of the contents of the entire record buffer.
2. present the data on-screen for the user to (possibly) update.
3. when the user has updated some fields, re-read the original
database record again, with record lock this time, into another
buffer and re-compute the check-sum or hash code. If the hash or
checksum is still t he same then no one else has updated the record
in the meantime, so it is now "safe" to update that record with
the changes made by the user. (The update will release the record
lock automatically.)
4. if the check-sum or hash does not "match" you need to release the
same record -- present the (newly updated) data again, and ask
the user to re-enter the changes. (... lather, rinse, repeat ..."UPDATEID" field to each file you want to update "lock-free" -- it can be a
as needed until the update is successful or the user presses
F12=Cancel ...)
_METHOD B -- a similar but simpler approach_
A simpler, low-cost variation on the above, relies on adding a single
binary integer or a packed numeric field, if binary, you can use a 2-byte
or 4-byte integer, or packed with at least 5 or more digits. Proceed as
follows:
changes. Instead of computing a checksum, you just remember theUPDATEID
* whenever a record is first added to the file, initialize this
UPDATEID field to zero. (Could be handled by an INSERT trigger)
* whenever any application program updates any record in this file,
you must ensure that the UPDATEID value is always incremented by 1
The algorithm for updating is similar to the above, with these
value ... and compare it , as follows:
rules_ to ensure that the UPDATEID is always incremented whenever a record
1. when you first read the record, (with no lock), save the UPDATEID
value for use later.
2. present the data on-screen for the user to possibly update.
3. when the user has updated some fields, re-read the original record
again, with a record lock this time, into another buffer and If the
UPDATEID is still t he same as the saved value, then no one else
has updated the record in the meantime, so it is now "safe" to
update that record with the changes made by the user. Increment the
value of UPDATEID in the record buffer about to be updated (This
update I/O will also release the record lock automatically.) (An
UPDATE trigger could handle incrementing the UPDATEID field.)
4. if the UPDATEID does not "match" you need to release the record lock
and inform the user, that the record has been updated by someone
else, and present the (newly updated) data again, and ask the user
to re-enter any changes. (... lather, rinse, repeat ... as needed
until the update is successful or the user presses F12=Cancel ...)
The main "down side" to METHOD B is that _everyone must follow these
is updated. (The "increment" logic could be put in a trigger to make that
part easier.) But, you must still add logic in your applications to
save the UPDATEID on the first READ and compare it again, just prior to
any update ... -- if anyone forgets orignores these rules, your users
will suffer "lost changes" like what happens if you use no record locking
at all.
record via a cobol pgm?
Hope that helps,
Mark S.Waterbury
On 8/5/2016 12:45 PM, Stone, Joel wrote:
What is a good way to handle record locks when a user changes a DB
recent changes.
Also how to avoid one user's changes from overlaying another user's
screen, then re-read with a record lock?
Is the best way to read with no lock, wait until user enters data into
reads by comparing the entire record strings?
And only update the record if there were no changes between the two
particular RRN during the users input?
Any other methods that work well?
Maybe read the journal to ensure no one else has changed that
record via a cobol pgm?
Thanks!
Joel
On 8/5/2016 12:45 PM, Stone, Joel wrote:
What is a good way to handle record locks when a user changes a DB
recent changes.
Also how to avoid one user's changes from overlaying another user's
screen, then re-read with a record lock?
Is the best way to read with no lock, wait until user enters data into
reads by comparing the entire record strings?
And only update the record if there were no changes between the two
particular RRN during the users input?
Any other methods that work well?
Maybe read the journal to ensure no one else has changed that
(COBOL400-L) mailing list
Thanks!
Joel
--
This is the COBOL Programming on the IBM i (AS/400 and iSeries)
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.
------------------------------
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 21
******************************************
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
