Re: Multi-member files - Big picture feedback

["Mike Eovino" <meovino@xxxxxxxxx>]

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.