Re: Disk space issues with not automatically deleted journal receivers

Hello Daniel,

Am 18.08.2025 um 07:40 schrieb Daniel Gross <daniel@xxxxxxxx>:

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.

Well, my assumption so far is: The i is made for databases. As such I expect database management to be possible without the need for a "local login". This is how I'm used to this scenario from databases on common platforms. Apparently, I'm wrong.

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

I see. I hoped this was possible without the need for "non-SQL" intervention.

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

Not that simple.

Please elaborate. Not that simple is better than "impossible". :-)

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

Seems like the currently best way to go, yes.

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.

Understood.

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.

I actually do for my consulting side, but for my hobbyist side, I very much want to keep the traditional way. It's much more appealing to me, as is the whole platform. Because it's so very refreshingly different to everything else I've experienced before. Also, I like the challenge of creating efficient programs, which is much more needed on a model 150 or even earlier CISC machines. I understand that this is contrary to what most people on this list think is "right", or "best". As said, this is my hobbyist side.

SQL/DDL has so many improvements over traditional DDS.

Yes. I'm learning.

In the end also SQL statements will gain performance.

Definitely not on V4R5 with the traditional query engine. ;-)

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.

Yes and no. I have experienced issues with RPG/5250 applications when the base tables/fields were created with CCSID(1208). But this is a lesser problem, because other people take over the existing stuff and create web interfaces based on Rust and .NET/Blazor running on Linux, connecting over ODBC. One of them told me that if Rust was available as native compiled language (not just in PASE), he'd be very interested in having those applications run on the i directly.

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.

Thanks. Tried that and failed for charset related reasons. It has been decided to largely scrap existing stuff and start fresh. That's easily possible because there is only little "original", non-redundant data.

:wq! PoC