MVSFORUMS.com Forum Index MVSFORUMS.com
A Community of and for MVS Professionals
 
 FAQFAQ   SearchSearch   Quick Manuals   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Less overhead calling (cobol)stored procedures

 
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Database
View previous topic :: View next topic  
Author Message
dr_te_z
Beginner


Joined: 08 Feb 2007
Posts: 18
Topics: 3

PostPosted: Tue Aug 28, 2007 6:38 am    Post subject: Less overhead calling (cobol)stored procedures Reply with quote

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 Smile

There are a lot of issues with compile/link/bind described here: http://www.redbooks.ibm.com/redbooks/SG247083/wwhelp/wwhimpl/js/html/wwhelp.htm
Suppose you've read it all and managed to compile/link/bind your stored procedures to enable both DB2 and COBOL calls.

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
               
         END-CALL
    ELSE EXEC SQL CALL 'S.ABC' ( :W-PARM01 :W-PARM01-NULL
                               , :W-PARM02 :W-PARM02-NULL  )
         END-EXEC
         IF SQLCODE = +466
         THEN PERFORM ASSOCIATE-ALLOCATE-FETCH-CLOSE-ABC
         END-IF
    END-IF.
900-090.
    EXIT.

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?
Back to top
View user's profile Send private message
kolusu
Site Admin
Site Admin


Joined: 26 Nov 2002
Posts: 12378
Topics: 75
Location: San Jose

PostPosted: Tue Aug 28, 2007 7:44 am    Post subject: Reply with quote

dr_te_z,

Check these excellent articles which discusses the same

http://www.dbazine.com/db2/db2-mfarticles/lawson2

http://www.db2mag.com/story/showArticle.jhtml?articleID=194300674

http://www.db2mag.com/qanda/041117-2.shtml

http://www-306.ibm.com/software/tivoli/features/ccr2/ccr2-2004-03/features-db2stored-pt1.html

Hope this helps...

Cheers

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu
Back to top
View user's profile Send private message Send e-mail Visit poster's website
dr_te_z
Beginner


Joined: 08 Feb 2007
Posts: 18
Topics: 3

PostPosted: Wed Aug 29, 2007 12:30 am    Post subject: Reply with quote

kolusu wrote:
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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Database All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
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


MVSFORUMS
Powered by phpBB © 2001, 2005 phpBB Group