Re: Multi-member files - Big picture feedback -- MIDRANGE-L

Actually, that is not true in this case.

I have an opportunity to rewrite a fairly extensive financialapplication that has used members for separating the individual fiscalyears of data and for keeping multiple clients information separate. Inone way it is pretty handy to have this flexibility in members, it alsois a hassle if I want to select across just a few members' data and doso on the fly. So what I am really looking for is something that willhave "legs" on the i5 and RPG. I embrace freeform RPG and I certainlyfeel more comfortable writing SQL statements (even in the clunky waythat V5R3M0 handles it in freeform RPG) I just want to be sure that I amnot trying to work "against" some native architecture on the i5 that Ishould be leveraging. If I bail on members, I'll need a fairlyefficient way to select, read and write to tables in the same manner Idid when overrides set the member fiscal year. I could make fiscal yearpart of the key and I could use a different collection for each client'sdata I suppose. That would simplify backup.

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

Not looking for a platform war, just good counsel on how to bestleverage 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*) useDDL/SQL techniques for DB I/O. Stay away from members (I am intriguedby what Rob said about SQL and multiple members though). And (the JoePluta rule) make tool decisions based on business needs (a given). HasIBM given general direction on this? My guess is that they will enhancewhat they endorse and let things wither for lack of enhancement thosethings 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