Re: NOUNREF option

LOL on the OAR thing. I don't know if the CLI stuff is any lighter-weight.

The pre-compiler stuff has been and continues to be problematic - I generally agree that I'd like to see something different. Database stuff is all done in Rochester - RPG is in Toronto, so far as I know. I don't know who does the pre-compiler, but my bet is on Rochester somewhere.

I was responding to Joe (?) - his comment that he wishes they'd just pass the SQL stuff to procedures - I think? That'd be very little different, seems to me, than what happens now - I'm not sure it would use early binding or late - the latter would have the same overhead to resolve to the service program, I believe.

There might be turf issues - just looking in from the outside here - that mean that the RPG team would not be putting direct calls into the compiler for embedded SQL. But I speak out of ignorance so had best shut up now!!

I'm giving a session on writing an OAR handler at COMMON this year - man, I'd better get it written soon, eh? It'll be on the rudimentary side - and will be covering a handler for DISK type files - not WORKSTN or PRINTER. The handler I wrote is using our product, not JDBC, but the idea is the same - whatever you use under the covers doesn't really matter architecurally. So CLI could be used just as well - I've managed to come up with how all the op-codes really work, that is, what they deliver. And basically get it done with SQL - it was an interesting exercise! Our product is forward-only, so I didn't support SETGT or any of the READP* operations. Now that makes me think - I COULD support them by doing what I would tell the customer to do, under the covers - huh, thanks for the blank wall support, man!!!

Cheers
Vern

On 4/6/2012 9:25 PM, Nathan Andelin wrote:

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.