|
> 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...)
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.