Posted: Tue Aug 28, 2007 6:38 am Post subject: Less overhead calling (cobol)stored procedures
I'd like to launch an idea of mine:
nowadays I'm coding COBOL stored procedures which are being called from WebSphere/java, other cobol programs and other cobol stored procedures.
It seems to me that cobol calling cobol by means of DB2/WLM generates a lot of overhead. But sometimes, when generating a result-set as output, it is mandatory.
But, when the output is represented as parameters, you might call the procudure the oldfashioned COBOL-way.
The company I work for is not open for that discussion right now. So, modest as ever, I want to discuss this with you: the rest of the world
Then you could call your procudures/modules like this
Code:
900-CALL-STORED-PROC SECTION.
900-010.
EXEC SQL
SELECT LANGUAGE , EXTERNAL_NAME , RESULT_SETS
INTO :LANGUAGE , :EXTERNAL-NAME , :RESULT-SETS
FROM SYSIBM.SYSROUTINES
WHERE OWNER = 'S'
AND ROUTINE_TYPE = 'S'
AND CREATED_BY = 'S'
AND NAME = 'ABC'
END-EXEC.
IF LANGUAGE = 'COBOL'
AND RESULT-SETS = ZERO
THEN CALL EXTERNAL-NAME USING W-PARM01,
W-PARM02,
W-PARM-NULLS
This is a theory and the code should be read as 'pseudo-code'.
Is there anybody out there who is able to test this. Tell me if it works and give some performance figures?
Check these excellent articles which discusses the same
Thanks, had not found them all myself. Especially this one (http://www.dbazine.com/db2/db2-mfarticles/lawson2) supports my case I'd say. My proposed solution could help preventing the danger of over-nesting as described there.
So, the "why" is fundamented enough, I propose the "how". Any comment on that?
Again, I am not in the position to trail-and-error myself. The company hired me to code and all the compile/link/bind jobs are encapsuled in home-cooked-tooling out of my reach.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum