Re: Multi-member files - Big picture feedback

Personally, I'd go with SQL/DDL.  And give everything both short
system names and long SQL names.  I think the latest issue of
iSeriesNetwork covers the gotchas of saving/restoring objects created
with SQL/DDL.  We haven't noticed any ill effects of running RPG over
them.

As for multi-member files, isn't that how IBM implements partitioned
SQL tables?  Maybe you could have the best of both worlds?

Mike E.

On 5/26/06, Pete Helgren <Pete@xxxxxxxxxx> wrote:

Let's say that you have the opportunity to rewrite an RPGIII based app
that uses multiple members in files that are poorly normalized.  This is
your opportunity to "do it right". The DB I/O will be in RPG primarily
and your target platform will be System i (although you may have other
JDBC/ODBC apps that access it).  You want to keep it relatively easy to
maintain because there will be plenty of need for backups, restores,
renaming of DB's either because the customer wants to set up test
environments or your company that provides the software occasionally
will do that either at a customer location at or at their own location.
You want to be leading edge without making your life miserable.  Which
direction do you "lean"?  To SQL/DDL tables or to DDS/Physical/Logical
files?

I have seen issues mentioned with SQL collections.  Primarily in saving
a "collection" and then restoring it under a different name.  Or,
renaming it in place.  True?

How about the relative merits of coding RPG against an SQL collection vs
a "traditional" files based library?  Seems to me that IBM has been
generally discouraging the use of "traditional" files and multiple members.

Is there any compelling reason to create multi-member files (which would
rule out SQL)?  Our current customers like the multi-member approach
which can be used in service bureau settings (member names reflect
customer "clients").  We also use multiple members for denoting data
sets between fiscal years.  Good news and bad news in that approach.
Some records sets in members can reach 200 million records.  Some files
may have 10-20 members.  More, if the customer is a service bureau that
has 20 customers with 10 years of data (200 members per file).

So, what do you all think?  Should we spend some time investigating
going down the SQL path or should we stick with what we have done in the
past (cleaning up the DB a bit by normalizing it, though).

Anyone had experience with this fork in the road and what the outcome was?

Thanks,

Pete Helgren

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