By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,830 Members | 1,746 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,830 IT Pros & Developers. It's quick & easy.

Calling a COBOL Subroutine from COBOL/DB2 Stored Procedure

P: n/a
Hi,

Has anyone called a COBOL subroutine using COBOL CALL from a COBOL/DB2
stored procedure? What are the complexities associated and what system
setting might be required?

Is this approach strategically better compared to converting the COBOL
subroutine into a stored procedure and then using a SQL CALL? This
COBOL subroutine is currently called by other COBOL and CICS programs
and will continue to be used there as well. If we covert it to a stored
procedure, other COBOL and CICS programs will also need to be changed.
But that effort is not a problem if converting this complex COBOL
subroutine into stored procedure is strategically beneficial in terms
of performance, debugging, future enhancements etc.

We have several such complex subroutines which are currently called
from COBOL and CICS programs. Now, there is a need for these
subroutines to be used real-time via web. We are planning to create new
stored procedures that will be called from web and these stored
procedures will in tern call the COBOL subroutines. We need to
strategically decide which way to go.

Thanks.

Nov 30 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
S > Has anyone called a COBOL subroutine using COBOL CALL from a COBOL/DB2
S > stored procedure? What are the complexities associated and what system
S > setting might be required?
The easy answer is that it depends.

We use this all the time. Standard sub-program call in COBOL. Just make
sure you use the same interface in both COBOL links. DSNRLI for WLM and
DSNALI or DSNRLI for SPAS.

It is actually less resource expensive to call a COBOL module than
another SP. We have stub SPs calling modules which are called by batch
programs which run on the same LPAR so we have a single source module when we
need to expose the function to off-LPAR processes. Remember why Sybase
succeeded with Stored Procedures in the first place, reduced processing
time by reducing the network trips.

Edward Lipson via Relaynet.org Moondog
ed***********@moondog.com el*****@bankofny.com
---
MM 1.1 #0361
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
Dec 1 '05 #2

P: n/a
Thanks for the response.

When I tried this, I am getting SQLCODE -927 from the 1st SQL statement
that gets executed from the called subroutine. Please note that my
called subroutine is a normal cobol program and not defined as a stored
procedure.

Dec 1 '05 #3

P: n/a
S > Thanks for the response.

S > When I tried this, I am getting SQLCODE -927 from the 1st SQL statement
S > that gets executed from the called subroutine. Please note that my
S > called subroutine is a normal cobol program and not defined as a stored
S > procedure.
Check the manual
http://publib.boulder.ibm.com/infoce...v2r2/index.jsp

You got the linked interface modules mixed up. They have to match. The
SP you call determines which interface any DB2 subprogram you call MUST
use. Not Bath, Not IMS, not TSO, not CICS. The SP.
Edward Lipson via Relaynet.org Moondog
ed***********@moondog.com el*****@bankofny.com
---
MM 1.1 #0361

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dec 2 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.