Re: CPF377F Save ended. Unable to reach checkpoint -- MIDRANGE-L

Thanks guys for all those useful insights.

I'm not too familiar with this EDI format so I can't tell if there are
natural logical boundaries there.
It's not your regular Orders/Shipments/Invoices kind.
rather it's a copyright (music) societies' proprietary old format called
EFM.
I will have a look though.

On the other hand only one file is involved in this transaction.

I will follow this up after the programmer commits the change (pun intended)

Gad

date: Thu, 26 Mar 2026 12:03:58 -0700
from: x y <xy6581@xxxxxxxxx>
subject: Re: CPF377F Save ended. Unable to reach checkpoint

Gad, IMO you should commit at a logical place, not necessarily every nnn
records, unless your application is smart enough to pick up where it left
off--and very, very few apps are written with that level of robustness.
It's faster, easier, and less failure-prone to use commitment control.

The point of commitment control is that it makes a transaction "atomic",
meaning "all or nothing". Now that we know atoms are made of many other
types of particles, "atomic" is no longer an accurate metaphor! A
modern database system will pass the ACID test: Atomic (the entire
transaction succeeds or fails), Consistent (the data state is valid),
Isolated (other database transactions don't affect this one), and Durable
(data is permanent once committed). Committing every nnn records will
break the atomic and consistency attributes for sure.

I suggest committing after every order (or nnn orders), not in the middle
of an order, or after a trading partner's last message or their set of
messages. Your goal should be to ensure a COMMIT takes place frequently
enough to allow the SaveWhileActive process to get a checkpoint while your
app is running. You may find you need to change the app slightly to keep
track of where the process is so restarting the app doesn't introduce more
problems.

My cash applications app has a header file (by customer/check) and a detail
file of invoice numbers and amount remitted. The program tags the header
record when its details have been processed and then I commit against a
dozen tables. If the app blows up in the middle of a run, the updates from
the current check will be rolled back. "Atomic" in this context means "the
check and its details have been processed". All the files changed during
the cash app update are journaled and commitment control makes the process
virtually bulletproof. When the job restarts, only the unprocessed checks
are selected and the user has no worries.

I call the use of commitment control an exercise in "defensive coding".
You assume things will break and you design/code/test/test again to handle
those issues proactively, without user input, and without
middle-of-the-night telephone calls.

On Thu, Mar 26, 2026 at 4:22?AM Gad Miron <gadmiron@xxxxxxxxx> wrote:

Thanks again guys

This is an home grown Web application that loads EDI files
that can be of considerable size, so it may be still running while the
nightly save kicks in.

Rob's replay got me thinking though,
I'll ask our web developer to commit every NNN records and not at file

end

only.

Txs you all
Gad

date: Wed, 25 Mar 2026 09:55:37 -0400
from: Rob Berendt <robertowenberendt@xxxxxxxxx>
subject: Re: CPF377F Save ended. Unable to reach checkpoint

And some might argue why are people not committing their transactions

in

a

timely basis? This may be what you really need to do. This may be
difficult in some situations. Thinking on your specific example and

the

client based program involved, you might need to train that developer

to

commit on a frequent basis, or to do their updates WITH NC. Or to

change

their odbc connection to one which can be defaulted to WITH NC

On Wed, Mar 25, 2026 at 9:36?AM Gad Miron <gadmiron@xxxxxxxxx> wrote:

Thanks Jim, Rob

I just wonder why IBM tolerates a situation
when an object cannot be saved because it's locked for other reasons.
- by issuing a CPF3761 Cannot use XXX in Library YYY

and do not tolerate a locked object by "commit pending"

Gad
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.