Re: Multi-member files - Big picture feedback

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