×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
-Nathan.
midrange.com
