Language Interface

Kenneth Larsen

Language Interface
We are compiling our Cobol programs with the DYNAM compiler option.
This way we can use the same modules under TSO & IMS,
as long as we concatenate the correct load library,
with the correct Language Interface first.
Now we would like to call the same modules
from a Stored Procedure.

Is this at all possible ?

Do we have to recompile all the modules with NODYNAM,
and then link edit them with DSNALI or DSNRLI ?

What about modules with IMS calls,
can the be called from a Stored Procedure ?
If not, what the heck .............................

Kenneth Larsen
Danish Payment Systems



Tim Lowe

Re: Language Interface
(in response to Kenneth Larsen)
Kenneth,
We currently support the use of the DYNAM compiler option in the DB2 stored
procedure environment by creating a copy of the proper language interface
module(DSNALI or DSNRLI depending on use of WLM) with an alias of DSNHLI.
This subject has been discussed extensively in the past on this list, you
may want to look into the archives.

As for calling IMS subroutines from DB2 stored procedures, you may again
find problems with interfaces since CBLTDLI is not supported in this
environment. I believe that AERTDLI must be used instead of AIBTDLI here,
which makes a big problem in trying to reuse existing IMS code. I do not
have an easy solution for this yet, we are just starting.

It does appear to me that in both cases, IBM has chosen the "easy way" out
for them, and given us a headache by not creating a couple of new
libraries. Personally, I would like to have seen support for CBLTDLI (or
at least AIBTDLI) from DB2 stored procedures. This would have made it
possible for us to leverage existing IMS code in this environment.
Maybe something will come in the future?

I hope this helps.

Thanks,
Tim



Kenneth
Larsen To: [login to unmask email]
<[login to unmask email]> cc:
Sent by: DB2 Subject: Language Interface
Data Base
Discussion
List
<[login to unmask email]
OM>


12/12/2000
02:17 AM
Please
respond to
DB2 Data Base
Discussion
List






We are compiling our Cobol programs with the DYNAM compiler option.
This way we can use the same modules under TSO & IMS,
as long as we concatenate the correct load library,
with the correct Language Interface first.
Now we would like to call the same modules
from a Stored Procedure.

Is this at all possible ?

Do we have to recompile all the modules with NODYNAM,
and then link edit them with DSNALI or DSNRLI ?

What about modules with IMS calls,
can the be called from a Stored Procedure ?
If not, what the heck .............................

Kenneth Larsen
Danish Payment Systems








Roger Miller

Re: Language Interface
(in response to Tim Lowe)
I think we chose the fast way that is well architected. Several requests
have come in lately that ask for a single stub. There is no existing
architecture to tell what environment we are in, e.g. IMS, CICS, TSO, batch,
stored procedure, USS, WebSphere, ... Not having an architecture means that
the interface is more likely to break and much more likely to require
changes. For some of those environments there are several possibilities for
the attachment. The attaches include IMS, CICS, command or TSO attach, Call
Attach and RRS. Getting the needed parameters to the modules is the next
challenge, along with handling the errors. There are a number of other
issues, such as getting storage as needed for the various environments.
There are some partial answers, but none that are complete.

The next problem we face is path length. If the module is linked in, then
the path length is very small. Once you make it dynamic and determine which
modules to call, you can double the path length or more. What I'd call this
is performance regression, also known as a release that many customers will
not migrate to.

Roger Miller, DB2 for OS/390



James Campbell

Re: Language Interface
(in response to Roger Miller)
But does the fact you provide a fast, well-architected set of LI modules
stop you _also_ providing a not-so-fast,
only-suitable-for-a-particular-set-of-circumstances single LI module that
could determine and use whatever attachment is currently active?

Let us determine which size fits our particular needs best. The previous
posts should indicate that some users are prepared to go to considerable
lengths to get a module to execute in different attaches.

/* standard disclaimer */
James Campbell
DBA
Hansen Corporation, Doncaster
+61 3 9843 8442
[login to unmask email]

-----Original Message-----
From: Roger Miller [mailto:[login to unmask email]
Sent: Thursday, December 14, 2000 6:29 AM
To: [login to unmask email]
Subject: Re: [DB2-L] Language Interface


I think we chose the fast way that is well architected. Several requests
have come in lately that ask for a single stub.

<snip>

What I'd call this
is performance regression, also known as a release that many customers will
not migrate to.

Roger Miller, DB2 for OS/390







**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************



Myron Miller

Re: Language Interface
(in response to James Campbell)
James, I agree with you. For some shops its a real
problem.

Roger,
My current client has an application with several
hundred subprograms. Some of these are IMS only, some
are DB2 only, some are both and some are neither. Its
a real MAJOR problem getting some of the main driver
programs linkedited correctly with all of these
subprograms due to the DSNHLI module being the same
name for IMS and DB2 but working differently. There
several main programs where some of them are IMS and
some of them are DB2 only that needed to call the same
subroutine. (IBM's solution - create duplicate
modules with different names for the IMS/DB2
environment versus the DB2 only environment - a very
significant task due to the hundreds of modules
involved. - Not counting the problems in maintenance
from then on.)

This was not a trivial task. The client would have
been much happier and significant amounts of time
would have been saved if there could have been a
single module that could have been linked into all the
relevant modules. And this amount of time does not
include all the time trying to get DB2 IBM support to
help resolve the problems. (Never did get resolved
from IBM - see their solution above - Tim Lowe
provided the best help thru the IMS list).

So having a common callable interface would actually
be useful in the our real world.
--- James Campbell <[login to unmask email]>
wrote:
> But does the fact you provide a fast,
> well-architected set of LI modules
> stop you _also_ providing a not-so-fast,
> only-suitable-for-a-particular-set-of-circumstances
> single LI module that
> could determine and use whatever attachment is
> currently active?
>
> Let us determine which size fits our particular
> needs best. The previous
> posts should indicate that some users are prepared
> to go to considerable
> lengths to get a module to execute in different
> attaches.
>
> /* standard disclaimer */
> James Campbell
> DBA
> Hansen Corporation, Doncaster
> +61 3 9843 8442
> [login to unmask email]
>
> -----Original Message-----
> From: Roger Miller [mailto:[login to unmask email]
> Sent: Thursday, December 14, 2000 6:29 AM
> To: [login to unmask email]
> Subject: Re: [DB2-L] Language Interface
>
>
> I think we chose the fast way that is well
> architected. Several requests
> have come in lately that ask for a single stub.
>
> <snip>
>
> What I'd call this
> is performance regression, also known as a release
> that many customers will
> not migrate to.
>
> Roger Miller, DB2 for OS/390
>
>
> To change your subscription options or to cancel
> your subscription visit the
> DB2-L webpage at http://www.ryci.com/db2-l. The
> owners of the list can be
>
>
>
>
**********************************************************************
> This email and any files transmitted with it are
> confidential and
> intended solely for the use of the individual or
> entity to whom they
> are addressed. If you have received this email in
> error please notify
> the system manager.
>
> This footnote also confirms that this email message
> has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
>
**********************************************************************
>
>
> To change your subscription options or to cancel
> your subscription visit the DB2-L webpage at
> http://www.ryci.com/db2-l. The owners of the list
> can


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/



Alan Smith

Re: Language Interface
(in response to Myron Miller)
This is an enormous problem for us too when we use dynamically-called
subroutines. Various hideous solutions have been used at our shop, including
linking all such routines as IMS, (so the top-level programs always have to
be IMS whether its is used or not), and putting a subroutine through the
compile/change procedure twice, so you get two different versions of the
same program.
Couldn't resolution of the module be put off until runtime, with different
versions in the IMS and DB2 libraries so that the one that gets picked up
depends on your concatenation? Or is that too simplistic?

Alan Smith


------------------------------

Date: Thu, 14 Dec 2000 07:59:54 -0800
From: Myron Miller <[login to unmask email]>
Subject: Re: Language Interface

James, I agree with you. For some shops its a real
problem.

Roger,
My current client has an application with several
hundred subprograms. Some of these are IMS only, some
are DB2 only, some are both and some are neither. Its
a real MAJOR problem getting some of the main driver
programs linkedited correctly with all of these
subprograms due to the DSNHLI module being the same
name for IMS and DB2 but working differently. There
several main programs where some of them are IMS and
some of them are DB2 only that needed to call the same
subroutine. (IBM's solution - create duplicate
modules with different names for the IMS/DB2
environment versus the DB2 only environment - a very
significant task due to the hundreds of modules
involved. - Not counting the problems in maintenance
from then on.)

This was not a trivial task. The client would have
been much happier and significant amounts of time
would have been saved if there could have been a
single module that could have been linked into all the
relevant modules. And this amount of time does not
include all the time trying to get DB2 IBM support to
help resolve the problems. (Never did get resolved
from IBM - see their solution above - Tim Lowe
provided the best help thru the IMS list).

So having a common callable interface would actually
be useful in the our real world.



Venkat (PCA) Pillay

Re: Language Interface
(in response to Alan Smith)
You are right. It is simple. I have done this by customizing the DSNHLI and
got good performance too by following few ROT.
Two easy ways to achieve this.

1. Write DSNHLI and follow LLE-CDE chain to find, which attachment is
loaded.
2. Check for the SQLCODE (Let DB2 chase LLE-CDE for you)

This will give you one version of DSNHLI that works for various attachment
facilities.

You could check my Dallas IDUG'99 presentation on "Exploiting DB2 Attachment
facility". If you are planning to customize and need any help, feel free to
discuss with me.

Regards,
Venkat Pillay
> -----Original Message-----
> From: Alan Smith [SMTP:[login to unmask email]
> Sent: Sunday, December 17, 2000 6:34 AM
> To: [login to unmask email]
> Subject: Re: Language Interface
>
> This is an enormous problem for us too when we use dynamically-called
> subroutines. Various hideous solutions have been used at our shop,
> including
> linking all such routines as IMS, (so the top-level programs always have
> to
> be IMS whether its is used or not), and putting a subroutine through the
> compile/change procedure twice, so you get two different versions of the
> same program.
> Couldn't resolution of the module be put off until runtime, with different
> versions in the IMS and DB2 libraries so that the one that gets picked up
> depends on your concatenation? Or is that too simplistic?
>
> Alan Smith
>
>
> ------------------------------
>
> Date: Thu, 14 Dec 2000 07:59:54 -0800
> From: Myron Miller <[login to unmask email]>
> Subject: Re: Language Interface
>
> James, I agree with you. For some shops its a real
> problem.
>
> Roger,
> My current client has an application with several
> hundred subprograms. Some of these are IMS only, some
> are DB2 only, some are both and some are neither. Its
> a real MAJOR problem getting some of the main driver
> programs linkedited correctly with all of these
> subprograms due to the DSNHLI module being the same
> name for IMS and DB2 but working differently. There
> several main programs where some of them are IMS and
> some of them are DB2 only that needed to call the same
> subroutine. (IBM's solution - create duplicate
> modules with different names for the IMS/DB2
> environment versus the DB2 only environment - a very
> significant task due to the hundreds of modules
> involved. - Not counting the problems in maintenance
> from then on.)
>
> This was not a trivial task. The client would have
> been much happier and significant amounts of time
> would have been saved if there could have been a
> single module that could have been linked into all the
> relevant modules. And this amount of time does not
> include all the time trying to get DB2 IBM support to
> help resolve the problems. (Never did get resolved
> from IBM - see their solution above - Tim Lowe
> provided the best help thru the IMS list).
>
> So having a common callable interface would actually
> be useful in the our real world.
>
>
>
>
>



James Campbell

Re: Language Interface
(in response to Venkat (PCA) Pillay)
But how much simpler it would be if, for non-CICS attachments, the
attachment had already loaded/IDENTIFYed common entry names (for HLI and
WLI). Then all your common routine would need to do is
- check TCBCAUF, if used then follow the same chain used by DSNCLI
(http://bama.ua.edu/cgi-bin/wa?A2=ind0011&L=ibm-main&P=R38980 was not denied
- not even by any of the IBMers on that list)
- if not used, then you have the fixed entry names to call.

In my dreams.

/* standard disclaimer */
James Campbell
DBA
Hansen Corporation, Doncaster
+61 3 9843 8442
[login to unmask email]

-----Original Message-----
From: Pillay, Venkat (PCA) [mailto:[login to unmask email]
Sent: Tuesday, December 19, 2000 12:33 AM
To: [login to unmask email]
Subject: Re: [DB2-L] Language Interface


You are right. It is simple. I have done this by customizing the DSNHLI and
got good performance too by following few ROT.
Two easy ways to achieve this.

1. Write DSNHLI and follow LLE-CDE chain to find, which attachment is
loaded.
2. Check for the SQLCODE (Let DB2 chase LLE-CDE for you)

This will give you one version of DSNHLI that works for various attachment
facilities.

You could check my Dallas IDUG'99 presentation on "Exploiting DB2 Attachment
facility". If you are planning to customize and need any help, feel free to
discuss with me.

Regards,
Venkat Pillay


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************



Venkat (PCA) Pillay

Re: Language Interface
(in response to James Campbell)
Doesn't have to be that complicated.

If the issue is to use same load module between TSO/CAF or RRSAF then there
is never a problem. But if CICS is involved even then it could be as simple
as the logic below, for a customized DSNHLI

Call WS-DSNCLI (contains value DSNCLI) and check for SQLCODE to check
the attachment
If not then Call WS-DSNELI or WS-DSNWLI2, whichever is appropriate.

Works great for me both in CICS as well as TSO. The user program (common to
CICS & TSO) would never have to be worried whether it runs in CICS or TSO
and has only one single load module !

The performance is not a hit while running in CICS, while the program is not
that critical in TSO so even if it hits during the first SQL call (coded in
such a way that it suffers just for the first SQL call), it doesn't matter.

The customized DSNHLI should be link-edited to the user program.

Here is one customization logic for DSNHLI, for programs to be used between
RRSAF/CAF and TSO using LLE-CDE search.
(A simpler version would just check for SQLCODE instead of LLE-CDE search)
The just a sample and not an ideal code (so, please don't find unnecessary
faults)

IDENTIFICATION DIVISION.
PROGRAM-ID. DSNHLI.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-HLI2 PIC X(8) VALUE 'DSNHLI2'.
01 SWITCH PIC S9(4) COMP-4.
01 PROGNAME PIC X(8) VALUE SPACES.
01 ADDRS-ADD PIC S9(9) COMP-4 VALUE 0.
01 START-POS PIC S9(9) COMP-4 VALUE 16.
01 PTR REDEFINES START-POS USAGE IS POINTER.
EXEC SQL
INCLUDE SQLCA
END-EXEC.
LINKAGE SECTION.
01 CVT PIC S9(9) COMP-4.
01 CVTPTR REDEFINES CVT USAGE IS POINTER.
01 TCBC PIC S9(9) COMP-4.
01 TCBCPTR REDEFINES TCBC USAGE IS POINTER.
01 TCB PIC S9(9) COMP-4.
01 TCBPTR REDEFINES TCB USAGE IS POINTER.
01 LLEPREV PIC S9(9) COMP-4.
01 LLEPREVPTR REDEFINES LLEPREV USAGE IS POINTER.
01 LLE PIC S9(9) COMP-4.
01 LLEPTR REDEFINES LLE USAGE IS POINTER.
01 CDE PIC S9(9) COMP-4.
01 CDEPTR REDEFINES CDE USAGE IS POINTER.
01 CDEVAL.
05 NXTCDE PIC S9(9) COMP-4.
05 FILLER PIC X(4).
05 PROG PIC X(8).
01 SQL-PLIST PIC X.
PROCEDURE DIVISION USING SQL-PLIST.
PERFORM GET-LLE
GOBACK.
GET-LLE.
SET ADDRESS OF CVT TO PTR.
MOVE CVT TO START-POS.
SET ADDRESS OF TCBC TO PTR
MOVE TCBC TO ADDRS-ADD.
ADD 4 TO ADDRS-ADD
MOVE ADDRS-ADD TO START-POS.
*
SET ADDRESS OF TCB TO PTR.
MOVE TCB TO ADDRS-ADD.
ADD 36 TO ADDRS-ADD
MOVE ADDRS-ADD TO START-POS.
*
SET ADDRESS OF LLEPREV TO PTR.
*
SET ADDRESS OF LLE TO LLEPREVPTR
MOVE LLE TO ADDRS-ADD.
ADD 4 TO ADDRS-ADD
MOVE ADDRS-ADD TO START-POS.
*
SET ADDRESS OF CDE TO PTR
MOVE CDE TO START-POS.
SET ADDRESS OF CDEVAL TO PTR
MOVE 1 TO SWITCH
PERFORM GET-CDE UNTIL SWITCH = 0.
GET-CDE.
MOVE PROG TO PROGNAME
MOVE NXTCDE TO START-POS.
IF NXTCDE = 0 THEN
MOVE 0 TO SWITCH
END-IF.
IF PROGNAME = 'DSNACAB ' OR PROGNAME = 'DSNACAF ' THEN
CALL WS-DSNHLI2 USING SQL-PLIST
END-IF
*
* SIMILARLY CALL OTHER ENTRY POINT DEPENDING ON ACTIVE
* ATTACHMENTS.
*
SET ADDRESS OF CDEVAL TO PTR.

Regards,
Venkat Pillay

> -----Original Message-----
> From: James Campbell [SMTP:[login to unmask email]
> Sent: Monday, December 18, 2000 7:47 PM
> To: [login to unmask email]
> Subject: Re: Language Interface
>
> But how much simpler it would be if, for non-CICS attachments, the
> attachment had already loaded/IDENTIFYed common entry names (for HLI and
> WLI). Then all your common routine would need to do is
> - check TCBCAUF, if used then follow the same chain used by DSNCLI
> (http://bama.ua.edu/cgi-bin/wa?A2=ind0011&L=ibm-main&P=R38980 was not
> denied
> - not even by any of the IBMers on that list)
> - if not used, then you have the fixed entry names to call.
>
> In my dreams.
>
> /* standard disclaimer */
> James Campbell
> DBA
> Hansen Corporation, Doncaster
> +61 3 9843 8442
> [login to unmask email]
>
> -----Original Message-----
> From: Pillay, Venkat (PCA) [mailto:[login to unmask email]
> Sent: Tuesday, December 19, 2000 12:33 AM
> To: [login to unmask email]
> Subject: Re: [DB2-L] Language Interface
>
>
> You are right. It is simple. I have done this by customizing the DSNHLI
> and
> got good performance too by following few ROT.
> Two easy ways to achieve this.
>
> 1. Write DSNHLI and follow LLE-CDE chain to find, which attachment is
> loaded.
> 2. Check for the SQLCODE (Let DB2 chase LLE-CDE for you)
>
> This will give you one version of DSNHLI that works for various attachment
> facilities.
>
> You could check my Dallas IDUG'99 presentation on "Exploiting DB2
> Attachment
> facility". If you are planning to customize and need any help, feel free
> to
> discuss with me.
>
> Regards,
> Venkat Pillay
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************
>
>
>
>
>