Re: Disk space issues with not automatically deleted journal receivers

Hi Patrik,

Am 17.08.2025 um 13:53 schrieb Patrik Schindler <poc@xxxxxxxxxx>:

Hello Daniel,

Am 17.08.2025 um 11:17 schrieb Daniel Gross <daniel@xxxxxxxx>:

This is only true, if you use the CREATE COLLECTION statement before creating you tables in that collection. This creates a library including default journal and receivers.

Uhm. It seems natural to do so?

Even if it seems - and creating a collection has some advantages over creating libraries and tables - I never have seen it in a professional environment.

But even if you want to do that, you need to correctly setup journaling to your needs afterwards.

If you create your library manually and do a STRJRNLIB, the tables that you later create with CREATE TABLE are automatically journaled in the same journal as the library, and you have full control.

Thanks for the hint. Will have a look at this.

So there is no way to tell CREATE COLLECTION to enable receiver deletion by default?

Not that simple.

I would recommend to stop the journaling completely after the creation. Then setup the journaling to your needs - and start it.

IMHO you should never leave journaling to the system defaults - whether is a production or test environment - even not for a personal playground.

I partly disagree. :-)

Defaults are there for a reason. I assume, someone did some serious thinking before setting them as they are.

The defaults are perfectly fine from IBMs PoV - they make sure, that nothing gets lost. No journal receivers are automatically deleted, because that would cause a loss of information by default - and that would not be acceptable.

So if this default is not what you want/need you have to set it up manually.

Since my personal playground is maintained very traditionally via DDS and CRT?F commands, I already have full control over journaling. :-)

You should level that up. SQL/DDL has so many improvements over traditional DDS. In the end also SQL statements will gain performance.

And that would be a pretty good exercise in database modernization. Here is a little scheme that Birgitta has proposed some time ago:

Define your table with SQL/DDL - maybe add additional columns for record id and temporal periods. And copy the data from the PF into the table.
Redefine your PF as an LF over the table with its own record format - use only the fields, the PF already had.
Redefine your LFs as LFs over the table - also use the record format that they already had.
Define additional indexes and views with SQL as you need.

If done right, the old RPG programs won't have to be recompiled and will work with the new LFs like nothing has happened. But they can't take advantage of the new columns.

With SQL only use the table for every access and let the optimizer find the optimal indexes.

You end up with an "hybrid" SQL/DDL + DDS database, that still supports your old programs, but also gives you all of the new SQL opportunities and a performance gain for SQL statements.

HTH
Daniel