Re: Journaling and Commitment Control

What Charles said.

IMO, serious developers use commitment control by default for most
applications. I don't journal or commit any work files (i.e., tables that
can be easily recreated with minimal processing) but all master and
transaction history are covered. Some of my operations programs update
more than 20 tables for one transaction (dispatching a truck updates
multiple vehicle master and transactions records, multiple driver master
and transaction records, payroll records, trailer and converter gear
records, manifests, load planning, and shipment records) and a failure
anywhere in the cycle cleans up dozens of adds and updates. From kicking a
power cord to having a system crash, commitment control saves your bacon.

With the exception of simple CRUD applications, most programs updating a
database are likely to touch multiple files. Commitment control is the way
to go.

--reeve

On Mon, Dec 4, 2023 at 8:10 AM Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

There is one downside of starting journaling...

By default, when a table is journaled and commitment control is NOT being
used, every write to the table forces a synchronous write to disk for the
journal entry.

This can have a big impact on large batch jobs which add/update a large
number of records.

In comparison, when commitment control is used, the system needs to only
write the journal entries to disk at the commit boundary; until then they
are cached in memory.

The issue became apparent years ago as people started journaling tables for
HA purposes. IBM came out with a Journal Caching PPRQ which allowed you to
turn on caching of journal entries even when commitment control wasn't
being used. That PPRQ is now an optional part of the OS.
5770-SS1 42 HA Journal Performance

As with everything, there's a trade off. When entries are cached and
you're not using commitment control, a system crash could lose a few
records.

More info:
https://www.ibm.com/docs/en/i/7.5?topic=journals-journal-cache
https://www.itjungle.com/2014/05/14/fhg051414-story03/

Don't let me scare you away from journalling, there are many benefits and I
wouldn't work somewhere without it.
Just an issue (and solution) to be aware of in case it crops up.

Lastly, if you happen to still have the old school "safety net" of
FRCRATIO(1) on your tables, then you're already doing a synchronous write
to disk for every write to a table. You'll probably want to look at
changing that *NONE is recommended for journaled tables. *NONE is a better
choice for performance even if the tables aren't journaled. But understand
the trade-off.

HTH,
Charles



On Fri, Dec 1, 2023 at 2:17 PM Greg Wilburn <
gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

Our legacy ERP system does not have journaling enabled on any of their
database files. I'm currently working on a UI modernization project, and
we would like to use commitment control in the new applications we're
creating (over the ERP database).

The ERP system using RPG record level access for everything. However, I
do have some custom programs accessing/updating these files using SQL.
Those programs set the commit option to *none.

So my question is this... if we enable journaling on these files, will
that affect any of the existing programs with the commit option = *none?

I've been reviewing the 2019 Articles on IT Jungle, and it seems like we
should be OK.

https://www.itjungle.com/2019/06/19/guru-classic-looking-for-commitment-part-1/

TIA,
Greg
[Logo]<https://www.totalbizfulfillment.com/> Greg Wilburn
Director of IT
301.895.3792 ext. 1231
301.895.3895 direct
gwilburn@xxxxxxxxxxxxxxxxxxxxxxx<mailto:gwilburn@xxxxxxxxxxxxxxxxxxxxxxx

1 Corporate Dr
Grantsville, MD 21536
www.totalbizfulfillment.com<http://www.totalbizfulfillment.com>
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.