THOSE programs ARE written by the SQL team, right?

I'm not sure which teams at IBM write which programs. Does it matter? I was just referring to the additional programs that are called and activated when you embed SQL in RPG programs. You can compare that to service program QRNXIO, which is activated when you embed "F" specs.

Use the DSPPGM and DSPPGMREF commands to follow the chain of program calls, service program activations, and procedures that are added to a *pgm object when you embed SQL or embed "F" specs in RPG. The chain of programs, service programs, and procedures required to support SQL is so large that you'd need a utility to map it, to more fully understand it. If you summed all the static storage required, that would be significant. But it still pales compared to the dynamic memory allocations required to manage huge networks of records.

By saying that, I hope people won't get the impression that I'm against SQL. Quite the contrary, we would REALLY miss it if we didn't have it. The extra overhead is worth it. It's just that RLA, is even more valuable to us than SQL.

Alan and I seem to be somewhat on the same page regarding IBM's RPG-SQL interface. That's to say I don't much like it from a programming point of view.

Vern, since you've already written an ROA handler for JDBC compliant databases, have you considered writing one as a wrapper around IBM CLI functions? RPG "F" specs could reference SQL VIEW objects, even ones with complex joins, views of other views, or whatever. You could provide an interface for "where", "group by", "order by" clauses just prior to an "open" op code. Then use RLA against an SQL result set.
I think that would be cool.


This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by 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].