Hi, my question was not getting any attention because it moved to 2nd
page; so posting it again. Sorry for any inconvenience but I need to
get it resolved fast. Need your help!
****************************************************************************************************
Original Question:
--------------------
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.
Reply by EDWARD LIPSON on Nov 30, 5:54 pm
-----------------------------------------
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.lip...@moondog.com elip...@bankofny.com
---
þ MM 1.1 #0361 þ
Reply by singlal on Dec 1, 10:06 am
------------------------------------
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.
Phil Sherman - 02 Dec 2005 15:07 GMT
Your question was well answered in the previous replies. You are facing
two conflicting goals:
1. No modifications to existing application code.
2. Need to run the subroutines in a new environment that has different
requirements from the existing environment.
There is a solution to your the requirements. It's not the necessarily
the best solution but it will allow use of a single progrma in multiple
environments.
You need to link two copies of your subroutine using (similar but)
different executable names. One is linked with DSNELI (or DSNALI) to
meet the needs of the existing environment. The other is linked using
the appropriate DB2 interface module for the stored procedure
environment you are using. This can be done by linking the object module
(from the compiler) twice, using the linkage editor NAME statement to
control the executable name. Your systems support programmer should be
able to help you with this.
Phil Sherman
> Hi, my question was not getting any attention because it moved to 2nd
> page; so posting it again. Sorry for any inconvenience but I need to
[quoted text clipped - 71 lines]
>
> procedure.
singlal - 02 Dec 2005 18:44 GMT
I appreciate your replies. Let me explain in a little detail what
exactly is going on:
I have not been able to successfully call a cobol subroutine from a
stored procedure yet. For now, I am keeping aside the issue of running
cobol subroutine in different environments. What I am trying now is
very simple. I am just trying to call the subroutine from stored
procedure. How we will call it from other environments, I'll worry
about that part later.
Now, in my environment, all the stored procedures are linked using
DSNALI option. As Edward suggested, I linked the cobol subroutine also
using DSNALI option. But I am still getting -927 from the 1st SQL
statement that gets executed in the called subroutine. Am I missing
something else here?
Thanks,
Lalit Singla