Re: Multiple members files

Hello,

thanks a lot for your thorough answer!


Am 17.11.2023 um 08:40 schrieb x y <xy6581@xxxxxxxxx>:

Without an file override or an alias in SQL, data will be added to the "first" member in the file. It appears the member list is unordered, so if you add members Z and A in that order, your naked data will land in member Z because it's the first in the internal member list.

Ah, now we're talking! Thanks for pointing this out!

You can open a file information data structure to pull the member name; it's in the RPG Reference Manual. I'm getting the member from positions 129-138.

Sounds like a perfect opportunity for some assurance output to the job log!

Remember there's a system limitation of 32,767 members in a file.

Since I'll reconcile the members on a yearly base, I'll probably not hit this limit during my remaining life time. ;-)

DO NOT use member logic in your transactions files--you will regret it.

What are "transaction files" in this particular context?

If you're trying to streamline your backup, I'd consider using journal data to build a file of changed records (with the journal control information attached); use the RECEIVE JOURNAL ENTRY command, or the API, or an SQL view.

This sounds like a huge undertaking, programmatically and a minor improvement to my workflow. I'll pass. :-)

Note: The data I'm inserting into said table is a recurring value of power my house uses vs. what's available from solar cells. The main reason to collect it is to automatically set my hot water boiler to a certain power draw, so only "leftover" energy is used to heat said water, and not the expensive grid power. The secondary reason is to derive statistics over the data. This is a project which evolves much slower than anticipated for various reasons. Parts of it are to be found here: https://github.com/PoC-dev/as400-hausauto

Writing programs to load and maintain the file is a day's work.

… for experienced people. :-)

Plan B: consider multiple data libraries. However, in thinking about this, I recognize it's a terrible idea...but it might work for your circumstance. The journal receiver idea--if you have or can create unique keys in the files you're working with--gets better as I think about it.

I don't see any advantage going that road. The file is keyed, though.

:wq! PoC