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

I'm sure...

But there's a risk using it, basically the original point of it is for
shops who don't use commitment control and only journalled their tables for
HA.

If your app was designed with commitment control, then it probably expects
a COMMIT'd transaction to be there in the event of a system failure. With
journal caching, this may not be the case.

OTOH, if you specifically build a batch processing app to
- use commitment control
- commit after every X records (~128KB)
- track where you're at in the input so you can restart

Then you get the same benefits of HA Journal Cache, without actually having
it on. As the system will by default cache the entries till COMMIT.

Now you could have HA Journal caching on, and commit for every record, but
you'd have needed to build/update the app so that you'll be able to tell
which records got dropped during a failure.

Charles

On Thu, Mar 26, 2026 at 2:17 PM Rob Berendt <robertowenberendt@xxxxxxxxx>
wrote:

We have HA Journal Performance on all machines.
Makes a HUGE difference in Journal performance. Freaking huge.
I believe it's a no charge item now.

On Thu, Mar 26, 2026 at 2:38 PM Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

I disagree Rob.

With "batch" processing of say 100k rows, the natural transaction
boundaries would be either 1 inbound row or all of them.
Even if each inbound row affects multiple tables, performance of so many
small transactions would be very poor. (unless you've got journal caching
turned on)

And if you tried to do all inbound rows in one transaction, that's going

to

be too big for comfort.

The best solution is to batch XX number of inbound rows as a single
transaction.

XX should be enough that the journal entries for the affected rows
(including journal entry overhead) comes close to 128KB (IIRC).

Charles

On Thu, Mar 26, 2026 at 10:31 AM Rob Berendt <

robertowenberendt@xxxxxxxxx>

wrote:

And that's the thing.
# of transactions should not be your goal. Your goal should be to

commit

at the transaction boundary.
The only exception being for some developer using iACS or some such

thing.

Did my update, check it out. Either "oops forgot where clause, issue
rollback" or "looks good - commit".

On Thu, Mar 26, 2026 at 11:40 AM Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx> wrote:

The other issue with significant numbers of uncommitted transactions

would

be in HA and abnormal terminations of the system.

If HA/Flashcopy backup and a snapshot is taken at the moment all

those

are

open, when the IPL of the Flash copy will take quite some time, since

the

DB will need to rollback all those transactions before it can call

the

database referential integrity good. That could be a significant

amount

of

time (hours in bad cases).

The same holds true for a single system if it crashes and has to IPL.
Think about applying PTFs, which ordinarily will cause an IPL. If

all

those transactions are still open, the same rules apply, the Database

must

insure referential integrity to proceed.

In the end it’s bad design and management of the system to leave

commits

open any longer than needed for the transaction boundary.

Jim Oberholtzer
Agile Technology Architects
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf

of

Charles Wilt <charles.wilt@xxxxxxxxx>
Date: Thursday, March 26, 2026 at 10:13 AM
To: Midrange Systems Technical Discussion <

midrange-l@xxxxxxxxxxxxxxxxxx

Subject: Re: CPF377F Save ended. Unable to reach checkpoint

Yeah, good plan...you really don't want large commits being done.

IIRC, there's actually not a hard system limit...if the system has

the

resources it will do it.

But from experience, while committing a large (100K maybe 1M ?)

transaction

isn't bad; if you need to roll it back it will take much longer.

Charles

On Thu, Mar 26, 2026 at 5: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.

--
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.

--
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.

--
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.