Comments on: SQLRPGLE Cursors and Recursion

By: dcantwell

dcantwell — Mon, 23 Nov 2009 13:08:06 +0000

Hmm…. Looks like this isn’t going to work the way I want it to.

It’s a little more elaborate than I’d like it to be. I wanted all the processing handled inside of the same program. I might just have to skip using SQLRPGLE and try something else.

Thanks for your help everyone!

By: philpl1jb

philpl1jb — Sat, 21 Nov 2009 11:40:29 +0000

Continuing on .. seperate cursors for levels would be necessary because when you return to a higher level you expect to pick up by fetching the next row from that level’s cursor.

By: philpl1jb

philpl1jb — Sat, 21 Nov 2009 11:38:27 +0000

no..but if you pass one more variable .. level – add one to it each level down and subtract one whenever you complete a level
and have seperate code based on a select where Level structure with 10 seperate cursors CursorLevel1 .. say to CursorLevel10.
You would then support 10 levels of recursion.

Phil

By: tomliotta

tomliotta — Fri, 20 Nov 2009 23:58:37 +0000

Hmmm… that bit about recursive program references assumes that pname comes out of ProgRec by way of “whfnam”…

Tom

By: tomliotta

tomliotta — Fri, 20 Nov 2009 23:50:24 +0000

I hope you don’t run across any recursive program references — there’s no way out that I can see if you do.

Assuming that a PR for printPrograms() would reference it as a proc…

I’m not at all confident that this would work. I would probably try having printPrograms() referencing an EXTPGM() rather than an internal (recursive) proc. I’d have that program run in a *NEW activation group to see how much control I could have over the SQL definitions and their relationships to available boundaries. By forcing each level into a new AG, you might be able to have scoping control over everything. Maybe.

But you still need to ensure that there are no recursive program references in DAVE.

Tom