Re: Multi-member files - Big picture feedback

[Pete Helgren <Pete@xxxxxxxxxx>]

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


Nathan Andelin wrote:

> Discussions like  these sometimes arise under the pretence of an architectural 
> question about  database access, but in the end are intended to justify, push, 
> and promote  platform agnostic development using Java and SQL.  Someone will 
> confirm that SQL  defined tables save an ounce of performance under read 
> access, and that will  justify giving up a pound of performance through the use 
> of distributed  architectures like .Net or J2EE.
>  
> The business case  for using multiple physical file members may be that an application requires  annual snapshots of configuration files to properly link to annual snapshots of  transactional data, and the application may already be using separate libraries  to separate data of multiple clients or multiple companies on a single  server, but since physical file members are specific to I5/OS, and that might  make it harder to migrate the database to another platform, then there must be  some justification for forbidding them.  Some people are simply opposed to using  I5 centric languages, tools, or development approaches.  I suspect that's what  this discussion is really about.
>  
>
>
>
> ----- Original Message ----
> From: Dave Odom <Dave.Odom@xxxxxxxxxxxx>
> To: midrange-l@xxxxxxxxxxxx
> Sent: Tuesday, May 30, 2006 12:00:10 PM
> Subject: RE: Multi-member files - Big picture feedback
>
> Ah here we go again...
>
> AS/400/iSeries/i5 record-at-a-time fundamentalism rears its head again.
>   The only problem about being in that camp is the rest of the RDBMS
> community laughs those folks out of the room and WORSE YET, out of the
> running when it comes to which platform is picked for a company's
> strategic direction.   The market place is the FINAL arbiter. 
>
> While on the surface, I agree with Joe the best tool should be used to
> solve the problem, he fails to understand the only tool accepted by the
> real-world RDBMS community is SQL.   To use any other access methodology
> is, on the one hand, considered a fundamental security breach as it is
> allowing a back door, something made quite clear as a "no-no" by Chris
> Date (also considered one of the founders of the RDBMS world and the
> person who brought Ted Codd's "laws" down the mountain so the real world
> could understand.)   On the other hand, using any other access
> methodology when doing true RDBMS access is not doing anything positive
> and strategic for your company, not to mention your resume.   
>
> I simply invite you to look at what access language the rest of the
> world is using when accessing the world-accepted and strategic RDBM's
> (the real DB2s, ORACLE and the like) and you will find its only SQL
> called from whatever language you wish to code in.   And that's what the
> rest of the non-i5 IT community has been purchasing for MANY years and
> the strategic direction by same for years to come.  
>
> Take care,
>
> Dave Odom
> Arizona          
>
>
>
>
>