DSNRLI

Rick McClendon

DSNRLI
I am extremely new to CAF processing - Can someone help me understand this?

I am trying to use DSNRLI to connect to DB2 so I can access a stored
procedure in a WLM environment.

I get an sqlcode of:
-991 CALL ATTACH WAS UNABLE TO ESTABLISH AN IMPLICIT CONNECT OR OPEN TO
DB2. RC1= rc1 RC2= rc2
Programmer Response: Verify that the application intended to use the call
attachment facility (CAF) as the mechanism to connect to DB2. For stored
procedures running in the WLM-established stored procedure address space the
application must be link-edited with or dynamically allocate the RRS
attachment language interface module (DSNRLI), not CAF.

Displays in the Cobol program seem to indicate that my attept to "CALL"
DSNRLI are successful - What am I doing wrong?
(Cobol Displays)
IDENTIFYING DB2 CONNECTION =DB2T
ID RETURN=0000000000
SIGNON TO DB2=DB2T
SIGNON = 0
CREATING THREAD TO DB2=DB2T
THREAD UNDER APPLICATION PLAN =FSUDBAPL
THREAD CREATED0000000000
SP CALL ERROR
SQLCODE:000000099J =(-991)



Eric Pearson

Re: DSNRLI
(in response to David Seibert)
Rick,
Add //DSNTRACE DD SYSOUT=* to your JCL and
you will get better CAF diagnostics.
Some are quite approachable (reason codes),
and some require access to the dread Diagnosis Reference.



regards,

eric pearson
NS ITO Database Support


-----Original Message-----
From: McClendon, Rick [mailto:[login to unmask email]
Sent: Tuesday, January 02, 2001 10:43 AM
To: [login to unmask email]
Subject: DSNRLI


I am extremely new to CAF processing - Can someone help me understand this?

I am trying to use DSNRLI to connect to DB2 so I can access a stored
procedure in a WLM environment.

I get an sqlcode of:
-991 CALL ATTACH WAS UNABLE TO ESTABLISH AN IMPLICIT CONNECT OR OPEN TO
DB2. RC1= rc1 RC2= rc2
Programmer Response: Verify that the application intended to use the call
attachment facility (CAF) as the mechanism to connect to DB2. For stored
procedures running in the WLM-established stored procedure address space the
application must be link-edited with or dynamically allocate the RRS
attachment language interface module (DSNRLI), not CAF.

Displays in the Cobol program seem to indicate that my attept to "CALL"
DSNRLI are successful - What am I doing wrong?
(Cobol Displays)
IDENTIFYING DB2 CONNECTION =DB2T
ID RETURN=0000000000
SIGNON TO DB2=DB2T
SIGNON = 0
CREATING THREAD TO DB2=DB2T
THREAD UNDER APPLICATION PLAN =FSUDBAPL
THREAD CREATED0000000000
SP CALL ERROR
SQLCODE:000000099J =(-991)








David Seibert

Re: DSNRLI
(in response to Rick McClendon)
Hi Rick,

I'm not sure I'll be able to help.

Is it your calling program that gets the -991?

It sounds like you might be confusing 2 different attachment facilities.
You reference CAF and the -991 does also. But you also mention DSNRLI.

There are 2 separate attachment facilities here (there are others too TSO
attach, IMS, CICS, ...)
- CAF is the older Call Attach Facility & uses Entry DSNALI
- RRSAF is the newer Recoverable Resources Manager Services Attach
Facility and is required for WLM-mangaged Stored Procedures & uses Entry
DSNRLI

It sounds like you are trying to use DSNRLI for your program that calls the
stored procedure. I believe you can, but you don't have to. If your S.P.
is WLM-managed, it must be linkedited with DSNRLI, but your caller doesn't
need to. If I had to guess, I'd say your code is CAF, but links in DSNRLI.
If that's the case, try changing your link-edit step for the calling program
to include DSNALI instead of DSNRLI. Your S.P. still needs to link (or
dynamically load) the DSNRLI module.
Please reply if necessary to clarify any incorrect assumptions made.

David Seibert
Compuware Corporation File-AID Product Architect
[login to unmask email]



Roland Schiradin

AW: DSNRLI
(in response to Eric Pearson)
DSNTRACE is for CAF (DSNALI)
For DSNRLI you need //DSNRRSAF DD DUMMY
but this will provide more debug-info in a SYSDUMP

Roland




> -----Ursprüngliche Nachricht-----
> Von: Pearson, Eric L, [SMTP:[login to unmask email]
> Gesendet am: Dienstag, 2. Januar 2001 16:59
> An: [login to unmask email]
> Betreff: Re: DSNRLI
>
> Rick,
> Add //DSNTRACE DD SYSOUT=* to your JCL and
> you will get better CAF diagnostics.
> Some are quite approachable (reason codes),
> and some require access to the dread Diagnosis Reference.
>
>
>
> regards,
>
> eric pearson
> NS ITO Database Support
>
>
> -----Original Message-----
> From: McClendon, Rick [mailto:[login to unmask email]
> Sent: Tuesday, January 02, 2001 10:43 AM
> To: [login to unmask email]
> Subject: DSNRLI
>
>
> I am extremely new to CAF processing - Can someone help me understand
> this?
>
> I am trying to use DSNRLI to connect to DB2 so I can access a stored
> procedure in a WLM environment.
>
> I get an sqlcode of:
> -991 CALL ATTACH WAS UNABLE TO ESTABLISH AN IMPLICIT CONNECT OR OPEN TO
> DB2. RC1= rc1 RC2= rc2
> Programmer Response: Verify that the application intended to use the call
> attachment facility (CAF) as the mechanism to connect to DB2. For stored
> procedures running in the WLM-established stored procedure address space
> the
> application must be link-edited with or dynamically allocate the RRS
> attachment language interface module (DSNRLI), not CAF.
>
> Displays in the Cobol program seem to indicate that my attept to "CALL"
> DSNRLI are successful - What am I doing wrong?
> (Cobol Displays)
> IDENTIFYING DB2 CONNECTION =DB2T
> ID RETURN=0000000000
> SIGNON TO DB2=DB2T
> SIGNON = 0
> CREATING THREAD TO DB2=DB2T
> THREAD UNDER APPLICATION PLAN =FSUDBAPL
> THREAD CREATED0000000000
> SP CALL ERROR
> SQLCODE:000000099J =(-991)
>
>
> visit
> the
>
>
>
>
> visit
>
>



Roland Schiradin

AW: DSNRLI
(in response to Roland Schiradin)
Please provide infos about your Binder/Linkage-editor statements

roland

> -----Ursprüngliche Nachricht-----
> Von: McClendon, Rick [SMTP:[login to unmask email]
> Gesendet am: Dienstag, 2. Januar 2001 16:43
> An: [login to unmask email]
> Betreff: DSNRLI
>
> I am extremely new to CAF processing - Can someone help me understand
> this?
>
> I am trying to use DSNRLI to connect to DB2 so I can access a stored
> procedure in a WLM environment.
>
> I get an sqlcode of:
> -991 CALL ATTACH WAS UNABLE TO ESTABLISH AN IMPLICIT CONNECT OR OPEN TO
> DB2. RC1= rc1 RC2= rc2
> Programmer Response: Verify that the application intended to use the call
> attachment facility (CAF) as the mechanism to connect to DB2. For stored
> procedures running in the WLM-established stored procedure address space
> the
> application must be link-edited with or dynamically allocate the RRS
> attachment language interface module (DSNRLI), not CAF.
>
> Displays in the Cobol program seem to indicate that my attept to "CALL"
> DSNRLI are successful - What am I doing wrong?
> (Cobol Displays)
> IDENTIFYING DB2 CONNECTION =DB2T
> ID RETURN=0000000000
> SIGNON TO DB2=DB2T
> SIGNON = 0
> CREATING THREAD TO DB2=DB2T
> THREAD UNDER APPLICATION PLAN =FSUDBAPL
> THREAD CREATED0000000000
> SP CALL ERROR
> SQLCODE:000000099J =(-991)
>
>
> visit
>
>



Rick McClendon

DSNRLI
(in response to Roland Schiradin)
Thank you all very much for the DSNRLI instructions - All of the
contributions helped. Here is what we ended up with:

*Stored Procedure compiled with ATTACH(RRSAF)- This translates the calls to
use DSNHLIR/DSNRLI
*Regular CAF compile of the calling program using DSNALI

My question now is - Why does it work & what Plan etc.... is RRSAF
connection running under?
The Cobol program runs CAF and connects under DSNALI, executes some SQL and
then calls the WLM stored procedure (that must use DSNRLI - not compatible
with DSNALI threads) - yet it executes just fine.
Thank you for any insight -

Rick McClendon - F.S.U. - (A moment of silence please for the loss of the
National champ. game last night) =:^(



Rick McClendon

DSNRLI
(in response to Rick McClendon)
I'm still confused about how this connection works -

*Stored Procedure compiled with ATTACH(RRSAF)- This translates the calls to
use DSNHLIR/DSNRLI
*Regular CAF compile of the calling program using DSNALI

The strange thing is that the RRSAF attach in the SP doesn't even appear to
be used, since the monitor shows the thread as a CAF thread. In addition,
the SP doesn't do any of the RRSAF calls (e.g. we didn't even code them!),
yet it appears that the SP uses the CAF thread/plan already allocated. In
the documentation it states not to mix the CAF with RRSAF, but strangely it
seems to work here. This particular piece of documentation sounds fishy,
since the above caveat about not mixing attaches implies that if/when I
convert my SPs to WLM, all of my existing applications will break.

Interestingly enough, it appears that when you code the SP with CAF
(ATTACH(CAF), just for grins right?), it gives you a SQLCODE that seems to
indicate that its trying to attach using the default ssid/plan. I would have
expected an SQLCODE that indicated I couldn't run WLM enabled SP using CAF.
This behavior was really more what I would've expected from the RRSAF
version without the necessary "identify", etc. calls.

Anybody know what gives?



Walter Janißen

Re: DSNRLI
(in response to Rick McClendon)
Hello

A few words to your last question:

SP always use the thread of the program calling the SP.
You cannot mix attachments in the very same adress space.

You can use SP with IMS or CICS transactions as well, which use a different
attachment (i.e. IMS use DFSLI000) than SPs.

Well the other things I don't know either, but it could be a problem of
your monitor.



Rick McClendon

Re: DSNRLI
(in response to Walter Janißen)
That's my point exactly -
"The SP will always use the thread of the program calling the SP"
The calling thread was created through DSNALI(CAF) and the SP is WLM and
must run under DSNRLI(RRSAF). The documentation says you cannot mix the CAF
with RRSAF - But because the SP is in it's own address space I can
understand why that portion would work.

The real question is -
What Explicit connection defaults are present in the DSNRLI thread? (if a
DSNRLI thread is created at all? - we can't find evidence that it is)

Since DSNALI and DSNRLI have such different connection needs, How is the
DSNRLI connection being "filled in"?

How is the WLM SP converting or opening a new DSNRLI thread(?) when the only
connection information given it is from creating a DSNALI connection?

Thank you for helping me understand this!

-----Original Message-----
From: Walter Janissen [mailto:[login to unmask email]
Sent: Friday, January 05, 2001 8:28 AM
To: [login to unmask email]
Subject: Re: DSNRLI


Hello

A few words to your last question:

SP always use the thread of the program calling the SP.
You cannot mix attachments in the very same adress space.

You can use SP with IMS or CICS transactions as well, which use a different
attachment (i.e. IMS use DFSLI000) than SPs.

Well the other things I don't know either, but it could be a problem of
your monitor.








Jeff Brokaw

Re: DSNRLI
(in response to Rick McClendon)
Rick

Stored procedures don't run require a plan, they use packages, and the
collection id must be specified on the CREATE PROCEDURE statement, and the
package must be bound on the server to do any DB2 work there.

The best fix, I would think, is to precompile your COBOL code (that calls
the procedure) with ATTACH(RRSAF) on the input parms to the precompile
step, to generate calls to DSNRLI instead of DSNALI (changing your link
parms as well of course, to pull in DSNRLI). Why does it work with a blend
of CAF/RRSAF? Don't know; might be one of those "results are
unpredictable" things. Seems kinda risky, if production code.

Jeff
[login to unmask email]



James Campbell

Re: DSNRLI
(in response to Jeff Brokaw)
The restriction on mixing attachment types is based on the address space.
The code that invokes an SP (if it's not an SP itself) is in a different
address space from the SP that is invoked. Hence the restriction is not
relevent.

If there are multiple error conditions (eg using DSNALI for an SP), the
error actually reported depends on the order that internal processing
occurs. Part of the joys(?) of debugging is to decipher the actual error in
such a situation.

I suppose part of the processing that happens 'under the covers' is to
create an appropriate attachment to DB2. Did you think that _all_ of
RRSAF's capabilities were documented?

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


-----Original Message-----
From: McClendon, Rick [mailto:[login to unmask email]
Sent: Saturday, January 06, 2001 12:10 AM
To: [login to unmask email]
Subject: [DB2-L] DSNRLI


I'm still confused about how this connection works -

*Stored Procedure compiled with ATTACH(RRSAF)- This translates the calls to
use DSNHLIR/DSNRLI
*Regular CAF compile of the calling program using DSNALI

The strange thing is that the RRSAF attach in the SP doesn't even appear to
be used, since the monitor shows the thread as a CAF thread. In addition,
the SP doesn't do any of the RRSAF calls (e.g. we didn't even code them!),
yet it appears that the SP uses the CAF thread/plan already allocated. In
the documentation it states not to mix the CAF with RRSAF, but strangely it
seems to work here. This particular piece of documentation sounds fishy,
since the above caveat about not mixing attaches implies that if/when I
convert my SPs to WLM, all of my existing applications will break.

Interestingly enough, it appears that when you code the SP with CAF
(ATTACH(CAF), just for grins right?), it gives you a SQLCODE that seems to
indicate that its trying to attach using the default ssid/plan. I would have
expected an SQLCODE that indicated I couldn't run WLM enabled SP using CAF.
This behavior was really more what I would've expected from the RRSAF
version without the necessary "identify", etc. calls.

Anybody know what gives?







**********************************************************************
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
**********************************************************************