Re: Multiple members files -- MIDRANGE-L

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.

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.

Remember there's a system limitation of 32,767 members in a file. DO NOT
use member logic in your transactions files--you will regret it. Name your
members so they won't be duplicated. You can get a huge number of unique
names out of four alpha characters (first character must be a "name" so you
have 29 possibilities). For the rest, you have 26 + 10 + @#$ and _. 29
*40 *40 *40 = lots of numbers. So, you can keep a huge number of members
with unique identifiers in multiple PF's online or as tables offline.

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. Writing programs to load and maintain the file is a day's work.
Restoring journals using IBM's tools won't work because that approach uses
relative record numbers, which will be a limitation right away. In short:
use journaling to catch changed records and roll you own programs to save
and recover them.

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.

On Thu, Nov 16, 2023 at 4:19 PM Patrik Schindler <poc@xxxxxxxxxx> wrote:

Hello,

I have a data PF to which I want to add multiple members on a monthly
base, effectively lessening the amount of data to copy to tape daily when
running savchgobj. When one record is changed in one huge member, the whole
member is saved. With separate „read only“ members, I assume only the
changed members since the last full-save (manual save or Save 21) are
saved. Is this correct?

I also assumed that new data is added to the alphabetically latest member,
which is surprisingly not the case and renders my concept moot. I‘ve
observed this on V4R5 without DB2 Multisystem installed.

My RPGLE application just opens the file and uses WRITE to create new
records. No overrides, no SQL, or other specialities are used so far. New
records end up in neither the first nor the last member, alphabetically as
well as order of prior running addpfm. This doesn’t even change when the
application is ended and restarted.

How does the system determine which member is used for new records, in a
multi-member data-PF?

I wanted to read about files and members to clarify this question myself
but I can‘t come up with the right place where this might be documented. I
remember to have seen a contemporary „Files“ documentation in PDF format
but I can‘t find it. So I guess my memory’s wrong and the name was
something else. Pointers to the correct documentation are welcome!

Thanks!

:wq! PoC
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.