Posted: Wed Oct 29, 2003 12:17 pm Post subject: SQL error while talking from IMS transaction to DB2
Hi all! Me again...
I have established a connection between IMS and DB2: command /DISPLAY SUBSYS ALL gives
Code:
SUBSYS CRC REGID PROGRAM LTERM STATUS
DSN % CONN
*97302/180029*
and I can use SSR to talk to DB2: /SSR %display database(dsndimst) gives
Code:
DSNT360I - ***********************************************************
DSNT361I - * DISPLAY DATABASE SUMMARY
* GLOBAL
DSNT360I - ***********************************************************
DSNT362I - DATABASE = DSNDIMST STATUS = RW
DBD LENGTH = 4028
DSNT397I -
NAME TYPE PART STATUS PHYERRLO PHYERRHI CATALOG PIECE
-------- ---- ---- ------------------ -------- -------- -------- -----
DSNSIMST TS RW
INDEX0 IX RW
******* DISPLAY OF DATABASE DSNDIMST ENDED **********************
DSN9022I - DSNTDDIS 'DISPLAY DATABASE' NORMAL COMPLETION
So, the link seems to be well established.
Unhappily, trying out my transaction (written in C, and asking a simple SQL SELECT to a DB2 table),
I get (in IVP51M41 joblog):
Code:
DSNT408I SQLCODE = -927, ERROR: THE LANGUAGE INTERFACE (LI) WAS CALLED WHEN THE CONNECTING ENVIRONMENT WAS NOT
ESTABLISHED. THE PROGRAM SHOULD BE INVOKED UNDER THE DSN COMMAND
DSNT418I SQLSTATE = 51006 SQLSTATE RETURN CODE
DSNT415I SQLERRP = DSNELI SQL PROCEDURE DETECTING ERROR
Of course I am not using the DSN command, because I am in IMS...
I am going to re-read the docs :-(
In the meantime, any hint..?
Hi Kolusu, thanks for your reply!
I am already linkediting with DFSLI000. Someone told me to pay attention to include the IMS version of the language interface for DB2 (not the DB2 batch version), and told me to put IMS.SDFSRESL (in my case SYS1.IMS.RESLIB) before DB2.SDSNLOAD. Now my JCL is (LKED part):
(before modifying it, there was also an INCLUDE SYSLIB(DSNELI)
before INCLUDE RESLIB(DFSLI000), and there was no SYS1.IMS.RESLIB
in the SYSLIB concatenation):
Now the result is different: calling the transaction with
TESTT 1 DE NUNZIO GIORGIO
I get:
Code:
DFS555I TRAN TESTT ABEND S000,U3042 ; MSG IN PROCESS:
TESTT 1 DE NUNZIO GIORGIO
97/302 19:54:59
DFS554A IVP51M41 00002 REGION TEST (1) TESTT 000,3042 PSB SMB
97/302 19:54:59 LTERM: USER1
I don't know if it is better or worse ;-(
As we are here, how do I communicate to IMS that I have recompiled
a transaction? It loads the module somewhere, and goes on using its
own copy even if I recompile/relink the transaction into IMS.PGMLIB...
Joined: 26 Nov 2002 Posts: 12375 Topics: 75 Location: San Jose
Posted: Wed Oct 29, 2003 4:50 pm Post subject:
Giorgio,
From your error message it is evident that both your program as well as PSB are stopped. You need to start your PSB and your program before you can invoke your transaction.
Hi Kolusu, thanks again for your help!
Unhappily, it does not seem so easy
My transaction starts with no problem: if I say:
Code:
TESTT 1 something
the transactoin uses SQL, while if I say
Code:
TESTT 2 something
it does not. In the latter case it works great. So the problem is just SQL!
More than one year ago member GUNZ had a similar problem (abend U3042) and solved it because, as he said:
Quote:
it happens due to the insufficient APF authorization for the dataset 'dsnxxx.dsnload'.
I have my SYS1.DB2.SDSNLOAD in PROGDB, loaded at startup fr authorization, so I think the problem is different, in my case...
I really don't know what to do...
A note about DFSESL: in a message you said, some time ago:
Quote:
SSM stands for Subsystem Member.You can find this value by looking in the dataset which is attached to the DD statement DFSESL.
In the manuals (IMS Install volume 2) I find, on the contrary:
Quote:
If JOBLIB/STEPLIB/LINKLIST concatenation is not authorized, you must use the DFSESL DD statement. For online IMS regions, the subsystem
library or libraries must be concatenated after the library containing the IMS modules (usually IMS RESLIB). When multiple subsystems are
connected, additional subsystem data sets can be concatenated.
Hi Bithead, thanks for your kind reply!
No, I have nothing like that. At least I don't think so...
What is your idea?
At present the situation is well stabilized, but it still does not work!
Let me repeat and correct here and there what I said in the preceding posts.
I have done everything (at least I think so) I should, to have my connection. I can do /SSR from my IMS Console, so the connection is working, but I have a strange message at the beginning (when connection is established) and an abend when I try to launch a transaction doing some SQL.
When doing a COLD start /NRE CHKPT 0 FORMAT ALL, IMS says...
This message means: "when I tried to load a module, even if the caller was authorized, that module was in an anauthorized library".
How can I discover what the module is??
everywhere (!) and these libs are authorized (they are in my PROGDB
PARMLIB member).
Then if I try and use SQL from my transaction TESTT, IMS abends (not when the transaction starts, but only when it tries to use SQL):
Code:
DFS555I TRAN TESTT ABEND S000,U3042 ; MSG IN PROCESS:
TESTT 1 DE NUNZIO GIORGIO
97/302 19:54:59
DFS554A IVP51M41 00002 REGION TEST (1) TESTT 000,3042 PSB SMB
97/302 19:54:59 LTERM: USER1
In a manual which is not a DB2 or IMS one, I read, about some possible IMS/DB2 abends:
(SAA Cross System Product Messages, Codes, and Problem Diagnosis)
Quote:
IMS 3042 Access to DB2 cannot be obtained. Possible causes of this are:
The terminal ID is not defined to DB2.
The DB2 application plan is not valid or cannot be accessed.
This can be a hint...
One more remark: my IMS.PROCLIB external susbystem member (I called it IVP4XDB2) contains the following ESMT: DSNMIN10. Changing it to something not existing (say XSNMIN10) gives this error message:
again followed by the two DFS3620I messages that absolutely do not change. This should mean that the two DFS3620I do not come from what is contained in IVP4XDB2 (that is, for instance, DSNMIN10): even if
this member is not loaded, I still have those messages absolutely as they
were before.
OK, now I know what the problem origin is NOT. I hope some day I find what the problem origin IS!
Hi!
Problem solved!!!
According to everybody's opinion, my DFS3620I at subsystem connection start, followed by an abend at SQL calls, was an authorization problem; but I could not understand why, as all necessary data sets (and even some unnecessary one, you never know..) were listed with APF ... statements in my PROG00.
But...
But I had not realized that some of these datasets were SMS-managed! I had not written "SMS" in their APF statements, but I had reported the current volume (VOLUME(USER04) or whatever). This is not good... After changing all those APF statements by substituting "VOLUME(xxxxxx)" with "SMS", everything began working!!!!! I could not believe my eyes...
OK, I should have realized it sooner...
This is the end of a nightmare...
Thanks again, and have a good week!
Ciao
Giorgio
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
