Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / DB2 Topics / December 2005

Tip: Looking for answers? Try searching our database.

Calling a COBOL Subroutine from COBOL/DB2 Stored Procedure

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
singlal - 30 Nov 2005 17:11 GMT
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.
EDWARD LIPSON - 30 Nov 2005 22:54 GMT
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
edward.lipson@moondog.com elipson@bankofny.com
---
þ MM 1.1 #0361 þ
singlal - 01 Dec 2005 15:06 GMT
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.
EDWARD LIPSON - 02 Dec 2005 02:13 GMT
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/infocenter/dzichelp/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
edward.lipson@moondog.com elipson@bankofny.com
---
þ MM 1.1 #0361 þ
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.