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.



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