RE: Modernization and multi-member files

Eric,

I could not agree with you more. But I have to say that IBM messed up
when they add feature to the database that can only be accessed via SQL.
So now you have features that you can only use via SQL and others that
are accessible via Native interface. SQL is a "Standard Query Language"
that SHOULD be the same regardless of the back end database. While
most database systems used to offer a native interface via API's that
was faster and more robust than the SQL interface. SQL was developed,
not by Microsoft, to give users the ability to look at their data stored
in a database for ad hoc reporting and analysis. It has since become
the defacto standard for accessing and updating data.

I think SQL is great if you are a software house and want your product
to run against multiple platforms and databases, but I like native
access for in-house development. But depending on what you are doing,
SQL and Native I/O are just tools to get the job done. Pick the one
that makes your job easier and gives you the performance you need.

For software developers, program in the language that will allow you to
install your software on the widest selection of systems available. But
make your software generic enough to run on MVS, OS400, Unix, Window and
what ever else there might be now and in the future.



Chris Bipes
Director of Information Services
CrossCheck, Inc.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DeLong, Eric
Sent: Thursday, July 17, 2008 7:53 AM
To: Midrange Systems Technical Discussion
Subject: RE: Modernization and multi-member files

Dave,

Please stop to consider this.... Security problem? Perhaps you are not
aware of the OS400 object security model, but it rather nicely and
consistently manages ANY access to the object and/or data, regardless of
HOW it is accessed. Do you realize that SQL uses the same methods to
access the database as an RPG read/chain/delete/etc? In this regard,
one COULD claim that OS400 is in fact closer to Codd's ideals, since
there is in fact only ONE channel for the user to access data. All
access to the DB is through the OS, and always subject to the same
controls.

So, you have created a table using DDL, and you secure it as needed.
Now, tell me how you can circumvent security to that table by using
native IO....... Please, give a concrete example for once, instead of
simply insisting that it is so.....

I could agree for any other platform, where the OS itself just treats
the data-store as a stream of bytes.... This is an inherent limitation
of those other platforms, because they do not differentiate between
object types. Everything is just a stream of bytes. Only OS400 was
built from the ground up to support an object model, integrating
database support at the very lowest layers of the OS. Not z, not p, not
x..... All of these provide database support as an add-on product. Not
native to the platform at all. Therefore, THOSE products are subject to
the limitations of the underlying OS. Security involving multiple
layers is hardly intuitive or failsafe. Those products are always much
more difficult to manage, because you must manage them at both the
product and the OS layers.

Please stop with the rhetoric for a moment, and lets have a reasonable
discussion. There is surely no doubt that most database designs
implemented on OS400 do not take advantage of the advanced database
features supported by the platform, but that hardly indicates the
inferiority of the product.