RE: Single record access really required (was RE: Views and

I figured I'd let Joe answer the part about IAAI since it's his baby.

As far as DB2/400 goes ( DB2 UDB for iSeries as it's know now.) I don't know
anything about VM or MVS DB2 so I don't quite understand your question but
I'm going to say no.

DB2 on the iSeries is built into and is an integral part of the operating
system itself.  Not to mention is has been that way from the beginning.

The OS is object based.  RDB data is stored in what is known as a physical
file, <object type(*FILE), object attribute (PF)>.  You could have an RPG
program doing I/O to the physical file MYFILE or you could use SQL to do
I./O to the MYFILE table.  In either case, the same object is being accessed
you're just using different interfaces to access the data in the object.

So it doesn't matter if you're using "native" RPG/COBOL record I/O or SQL to
access the data the same security mechanisms are in place and handled by the
OS.

HTH,
Charles


> -----Original Message-----
> From: Dave Odom [mailto:Dave.Odom@xxxxxxxxxxxx]
> Sent: Tuesday, July 27, 2004 2:54 PM
> To: midrange-l@xxxxxxxxxxxx
> Subject: RE: Single record access really required (was RE: Views and
> 
> 
> A couple of questions on this argument:
> 
> What does IAAI stand for and how are they involved with performance
> issues?
> 
> Is DB2/400 like VM & MVS DB2, such that when you create tables inside
> of DB2 you can't read the data except with SQL and the security inside
> of theDB2 engine?  If that is true, then I prefer SQL for programming
> applications, at least from the security aspect.   And, if the DB2/400
> optimizer is anything like the VM/MVS DB2 optimizer, I'd say 
> that you'll
> get better performance with DB2 over the keyed-sequence 
> record-at-a-time
> access of the native 400 I/O but usually only IF you have 
> large numbers
> of records.  The reason for this is because the DB2 Optimizer makes
> decisions on how to best get your data, and those decisions may change
> day-to-day, whereas the keyed sequence approach goes through keys and
> follows much the same path regardless of how circumstances 
> have changed
> and may not be the best performer.   It is important to make
> apples-to-apples comparisons as far as the data and the application
> architecture.   I hope, if the IAAI is into performance 
> comparisons the
> comparison test are set up in a fair manner using the coding access
> strategy best for each access method and not forcing a key-sequence
> approach using SQL or vice versa. 
> 
> FWIW,
> 
> Dave Odom
> 
> --
> This is the Midrange Systems Technical Discussion 
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>