LE interface for SPAS

teldb2kals

LE interface for SPAS
Hi,

Thanx to all those who helped me get an understanding of the LE
interface modules and the DYNAM/NODYNAM compile options for stored
procedures and subroutines. I now have a few more questions.

1. If using DYNAM option, the use of a stub module which loads
DSNALI, or creating an alias of DSNHLI for DSNALI has been suggested.
What sort of a performance impact does this have as compared to
including it in the Link step and using NODYNAM ? I have seen a couple
of mails on the list pointing out that dynamic loading might lead to an
increase in path length and hence cd result in peformance degradation.

2. While creating the alias of DSNHLI, what is the right way to go
abt it?

(a) Copy the DSNALI module from the system dataset into a
separate dataset and create an alias in the same dataset using the
Linkage-editor ?
(b) Directly link the DSNALI module from the system dataset
renaming it as DSNHLI and store it in the separate dataset ?

I tried option (b) but that didnt work.

3. While creating the alias, shd I specify ENTRY DSNHLI2 or ENTRY
DSNHLI or leave it to default (which is DSNAA). ? All of them seem to
work.

4. Does anybody have an example of the stub program for DSNHLI to use
to point to the DSNALI interface ?

Thanx.

Cheers,
Kals


----------------
Powered by telstra.com



Lee Hayden

Re: LE interface for SPAS
(in response to teldb2kals)
Below is a little asm stub that loads DSNALI and sets entry
points to intercept standard DB2 (HLI) calls. I don't use
this much anymore as the precompiler now allows ATTACH(CAF).

Here is sample COBOL driver code:

* MAKE CAF AND OTHER SERVICES AVAILABLE
*
CALL "CAFLOAD".
*
*
* OPEN CONNECTION TO CAF
*
MOVE "CONNECT" TO ACTN.
MOVE PARMS-SSID TO SSID.
CALL "DSNALI" USING ACTN
SSID TECB SECB RIBPTR RETC REAS.
DISPLAY "CONNECT RETURN CODE=" RETC.
*
* OPEN FUNCTION TO CAF
*
MOVE "OPEN" TO ACTN.
MOVE PARMS-PLAN TO PLAN.
CALL "DSNALI" USING ACTN SSID PLAN RETC REAS.
DISPLAY "OPEN RETURN CODE=" RETC.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

TITLE 'C A F L O A D - DB2 CAF INTERFACE'
CAFLOAD AMODE ANY
CAFLOAD RMODE ANY
CAFLOAD CSECT
*----------------------------------------------------------------------
* REGISTER USAGE FOR CAFLOAD
*----------------------------------------------------------------------
R0 EQU 00
R1 EQU 01 ADDRESS OF LIST OF PARMETER ADDRESSES
R2 EQU 02
R3 EQU 03 CAFLOAD BASE REGISTER
R4 EQU 04
R5 EQU 05
R6 EQU 06
R7 EQU 07
R8 EQU 08
R9 EQU 09
R10 EQU 10
R11 EQU 11
R12 EQU 12
R13 EQU 13 SAVE AREA AND GLOBAL WORK AREA
R14 EQU 14
R15 EQU 15
*
* SETUP
*
SAVE (14,12),,* STANDARD LINKAGE
LR R12,R15 ESTABLISH BASE REG
USING CAFLOAD,R12 TELL ASSEMBLER
STORAGE OBTAIN,LENGTH=SAVEL GET SAVE AREA STORAGE
ST R13,4(,R1) SAVE CURRENT R13
ST R1,8(,R13) LINK BACK
LR R13,R1 NEW BASE
USING SAVEAREA,R13 TELL ASSEMBLER
*
* LOAD IN DSNALI MODULE AND ALIASES
*
LOAD EP=DSNALI
ST R0,SAVEALI
LOAD EP=DSNHLI2
ST R0,SAVEHLI
LOAD EP=DSNWLI2
ST R0,SAVEWLI
*
* ESTABLISH ALTERNATIVE ENTRY POINT NAMES
*
L R2,SAVEHLI
IDENTIFY EP=DSNHLI,ENTRY=(R2)
L R2,SAVEWLI
IDENTIFY EP=DSNWLI,ENTRY=(R2)
*
* RETURN TO CALLER
*
LR R2,R13
L R13,SAVE+4
STORAGE RELEASE,LENGTH=SAVEL,ADDR=(R2)
RETURN (14,12),T,RC=0
*
* CONSTANTS
*
LTORG
*
* DSECTS
*
SAVEAREA DSECT
SAVE DS 18F
SAVEALI DS A
SAVEHLI DS A
SAVEWLI DS A
CNOP 0,8
SAVEL EQU *-SAVEAREA
END CAFLOAD
/*

-----Original Message-----
From: teldb2kals [mailto:[login to unmask email]
Sent: Thursday, January 10, 2002 1:19 AM
Subject: LE interface for SPAS


Hi,

Thanx to all those who helped me get an understanding of the LE
interface modules and the DYNAM/NODYNAM compile options for stored
procedures and subroutines. I now have a few more questions.

1. If using DYNAM option, the use of a stub module which loads
DSNALI, or creating an alias of DSNHLI for DSNALI has been suggested.
What sort of a performance impact does this have as compared to
including it in the Link step and using NODYNAM ? I have seen a couple
of mails on the list pointing out that dynamic loading might lead to an
increase in path length and hence cd result in peformance degradation.

2. While creating the alias of DSNHLI, what is the right way to go
abt it?

(a) Copy the DSNALI module from the system dataset into a
separate dataset and create an alias in the same dataset using the
Linkage-editor ?
(b) Directly link the DSNALI module from the system dataset
renaming it as DSNHLI and store it in the separate dataset ?

I tried option (b) but that didnt work.

3. While creating the alias, shd I specify ENTRY DSNHLI2 or ENTRY
DSNHLI or leave it to default (which is DSNAA). ? All of them seem to
work.

4. Does anybody have an example of the stub program for DSNHLI to use
to point to the DSNALI interface ?

Thanx.

Cheers,
Kals


----------------
Powered by telstra.com



teldb2kals

Re: LE interface for SPAS
(in response to Lee Hayden)
Hi Lee,

Thanx for that. Will try it and see how it goes.

Have a good weekend.

Cheers,
Kals


-----Original Message-----
From: Hayden, Lee [SMTP:[login to unmask email]
Sent: Friday, January 11, 2002 12:47 AM
To: [login to unmask email]
Subject: Re: LE interface for SPAS

Below is a little asm stub that loads DSNALI and sets entry
points to intercept standard DB2 (HLI) calls. I don't use
this much anymore as the precompiler now allows ATTACH(CAF).


----------------
Powered by telstra.com