Re: Multi-member files - Big picture feedback

I forgot to point out that in the event that multi-member tables needed to be 
access by ODBC or JDBC clients, you could write a single program to perform the 
member override logic for all applications.  If there happened to be moderately 
complex logic involved in doing member overrides, then make the logic table 
driven so it could be encapsulated in just one program.  Almost any ODBC or 
JDBC client can make simple program calls after establishing a connection.

In the case of Excel or similar clients, I'd suggest using the SQL2STMF 
command, which I wrote to dump the output from SQL Select statements to CSV 
formatted stream files, rather than allowing Excel users to access production 
files via ODBC.



----- Original Message ----
From: Pete Helgren <Pete@xxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, May 30, 2006 2:51:27 PM
Subject: Re: Multi-member files - Big picture feedback

Actually, that is not true in this case.

I have an opportunity to rewrite a fairly extensive financial 
application that has used members for separating the individual fiscal 
years of data and for keeping multiple clients information separate.  In 
one way it is pretty handy to have this flexibility in members, it also 
is a hassle if I want to select across just a few members' data and do 
so on the fly.  So what I am really looking for is something that will 
have "legs" on the i5 and RPG.  I embrace freeform RPG and I certainly 
feel more comfortable writing SQL statements (even in the clunky way 
that V5R3M0 handles it in freeform RPG) I just want to be sure that I am 
not trying to work "against" some native architecture on the i5 that I 
should be leveraging.  If I bail on members, I'll need a fairly 
efficient way to select, read and write to tables in the same manner I 
did when overrides set the member fiscal year.  I could make fiscal year 
part of the key and I could use a different collection for each client's 
data I suppose.  That would simplify backup.

This will be an iSeries specific application.  It might be nice to get 
some reuse out of some of the modules that do DB I/O but perhaps using 
traditional DDS and native I/O is all I should expect to be able to 
use.  Again, I'd like to use more "leading edge" RPG techniques and 
leverage the iSeries database in a "21st century" way.  I expect the 
application to be maintained by RPG programmers in the future and I am 
guessing RPG400 and native I/O might be a "foreign" concept to them.

Not looking for a platform war, just good counsel on how to best 
leverage this awesome box called the i5 when it comes to writing RPG 
(OK, David, perhaps this should go to the RPG list...). 

Based on what I have heard so far the consensus is (in *general*) use 
DDL/SQL techniques for DB I/O.  Stay away from members (I am intrigued 
by what Rob said about SQL and multiple members though).  And (the Joe 
Pluta rule) make tool decisions based on business needs (a given).   Has 
IBM given general direction on this?  My guess is that they will enhance 
what they endorse and let things wither for lack of enhancement those 
things they want to "go away".

Pete Helgren