Re: Multi-member files - Big picture feedback

If native I/O is a  foreign concept to people brought up on SQL, it won't be to 
RPG programmers of  the future.  In fact, if RPG were to take on a new name, 
then IDL (an acronym  for Integrated Data Language) would be a good one.  
Record level access  is fundamental as well intrinsic to the language, and will 
be in the future, as  far as I can see.
  
 Adding fiscal year  as a column in a table is a database design concern.  
Would it take an otherwise  normalized table and reduce the level of 
normalization?  Would it lead to  redundant repeating values in columns?
  
 Backing up files  may be a consideration.  The member option of the SAVOBJ 
command could be used  to backup only members pertaining to the current fiscal 
year, and bypass members  of prior fiscal years that are only used for inquiry, 
no longer for  transactions.
  



----- 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