Re: SQL vs native access

> And as a followup, I'd still be interested to see how an SQL SLIC
> primitive could somehow be faster than the same primitive for native
> I/O.  For a single record keyed CHAIN on a native file, it's pretty much
> search the index for the key (this is all low-level), then retrieve the
> record pointed to.  How exactly are you going to do this faster in SQL?

Well, if the SQL stuff is done at a lower level than the native stuff, then
I can see how.  For instance, RPG calls an OS400 routine called QDBGETKY for
a CHAIN.  You can see it in your call stack.  (Speculation begins here)
QDBGETKY calls SLIC services to traverse keyspace and some more SLIC
services to fetch the appropriate PF record into the database buffer.  RPG
then gets to map the database buffer into it's internal field name table
(our beloved externally copied in I specifications).

If SQL can now directly call a different SLIC service (different feedback
requirements?) then it avoids the overhead of QDBGETKY.

Here's an interesting tangent... write a simple program that only does a
CHAIN and compile it with genopt(*list *xref) and look at the generated MI
for the CHAIN; don't miss the CALLI to .XRVRC01 which in turn does a CALLX
to .IOEPTR.
  --buck (who doesn't believe in magic either...)