Re: Disk space issues with not automatically deleted journal receivers

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?

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?

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.

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

You need to define a journaling and backup "strategy" first - otherwise you risk losing data.

Journaling to me is mainly a vehicle for enabling transactional processing. The backup strategy on the machines I'm involved with was considered adequate, without .

But nothing is set in stone, and maybe tomorrow, a more fine-grained strategy might be required. But that's something to consider when the decision comes up. It's not up to me. I'm just helping to my best abilities.

I have no better idea what to do but use wrklib option 12 for every SQL created library, and delete all but the highest numbered receivers. This makes me lose receivers which haven't been saved (by the automatic daily savchgobj), yet.

Use the JOURNAL_RECEIVER_INFO view to find the receivers, that are detached and on already have a "last saved" date - these are the ones to delete.

Thanks!

:wq! PoC