dsnrexx fails without error message

jaylhaskin · Posted: Tue Sep 20, 2022 3:17 am

I am trying to connect to a db2 subsystem using the following code block:

"SUBCOM DSNREXX"
IF RC THEN
S_RC = RXSUBCOM('ADD','DSNREXX','DSNREXX')

ADDRESS DSNREXX "CONNECT" SSID
IF SQLCODE <> 0 THEN CALL SQLCA

This always results in a call to SQLCA which is a REXX subroutine which prints out the SQLCA variables and exits.

The problem is none of the SQLCA variables are set. For instance, SQLCODE="SQLCODE", not a nonzero numerical result.

I would appreciate some ideas to troubleshoot this issue...

dneufarth · Posted: Tue Sep 20, 2022 4:30 am

Try ibmmainframes.com/about47469.html

Found on a forum search

Willy Jensen · Posted: Tue Sep 20, 2022 1:28 pm

Shouldn't 'IF RC THEN' be 'if rc<>0 then' ?
Assuming that SUBCOM DSNREXX sets rc as is normally done, with rc=0 when successful, then your 'THEN' will be taken when rc is not 0 - when SUBCOM DSNREXX failed. Though the statement would probably would fail with IRX0034I Logical value not 0 or 1.

jaylhaskin · Posted: Tue Sep 20, 2022 8:09 pm

Thank you Dave and Willy for your prompt replies.

I had read that forum post about RXSUBCOM but it didn't seem to apply since I am not getting any error at all other than the fact that the rxsubcom didn't seem to work as the REXX variable SQLCODE had not been assigned a value.

I can post the trace here if it will help, the RC code worked properly in the trace it showed a value of 0 so the code worked properly by skipping the RXSUBCOM statement and going right to the connect statement.

The connect statement did not throw an error but the following line does go to SQLCA routine where it reports that SQLCODE = "SQLCODE". Since SQLCODE variable is not equal to zero the connect failed however, it isn't really failing since SQLCODE was not set indicating that DSNREXX isn't loaded. But if that is true, why did the "SUBCOM DSNREXX" return an RC = 0?

I will attach a trace to show the details:

41 *-* call setup_env_and_connect
130 *-* setup_env_and_connect:
132 *-* whereat = 'subcom'
>>> "subcom"
133 *-* "SUBCOM DSNREXX" /* HOST CMD ENV AVAILABLE? */
>>> "SUBCOM DSNREXX"
134 *-* IF RC
>>> "0"
136 *-* S_RC = RXSUBCOM('ADD','DSNREXX','DSNREXX')
>>> "0"
138 *-* ADDRESS DSNREXX "CONNECT" SSID
>>> "CONNECT XXXX"
139 *-* IF SQLCODE <> 0
>>> "1"
*-* THEN
*-* CALL SQLCA
146 *-* sqlca:
147 *-* say 'We are in SQL CA, something bad happened'
>>> "We are in SQL CA, something bad happened"
We are in SQL CA, something bad happened
148 *-* say 'WHERE AT = ' whereat
>>> "WHERE AT = subcom"
WHERE AT = subcom
149 *-* /*say 'SQLSTMT = ' sqlstmt */
151 *-* /*if SQLCODE = "SQLCODE" THEN RETURN*/
153 *-* SAY 'SQLCODE ='SQLCODE
>>> "SQLCODE =SQLCODE"
SQLCODE =SQLCODE
154 *-* SAY 'SQLERRMC ='SQLERRMC
>>> "SQLERRMC =SQLERRMC"
SQLERRMC =SQLERRMC
155 *-* SAY 'SQLERRP ='SQLERRP
>>> "SQLERRP =SQLERRP"
SQLERRP =SQLERRP
156 *-* SAY 'SQLERRD ='SQLERRD.1',', || SQLERRD.2',',
|| SQLERRD.3',', || SQLERRD.4',',
|| SQLERRD.5',', || SQLERRD.6
>>> "SQLERRD =SQLERRD.1,SQLERRD.2,SQLERRD.3,SQLERRD.4,SQLERRD.5,SQLERRD.6"
SQLERRD =SQLERRD.1,SQLERRD.2,SQLERRD.3,SQLERRD.4,SQLERRD.5,SQLERRD.6
162 *-* SAY 'SQLWARN ='SQLWARN.0',', || SQLWARN.1',',
|| SQLWARN.2',', || SQLWARN.3',',
|| SQLWARN.4',', || SQLWARN.5',', || SQLW
ARN.6',', || SQLWARN.7',', || SQLWARN.8',
', || SQLWARN.9',', || SQLWARN.10
>>> "SQLWARN =SQLWARN.0,SQLWARN.1,SQLWARN.2,SQLWARN.3,SQLWARN.4,SQLWARN.5,SQLWARN.6,SQLWARN.7,SQLWARN.8,SQLWARN.9,SQLWARN.10"
SQLWARN =SQLWARN.0,SQLWARN.1,SQLWARN.2,SQLWARN.3,SQLWARN.4,SQLWARN.5,SQLWARN.6,SQLWARN.7,SQLWARN.8,SQLWARN.9,SQLWARN.10
173 *-* SAY 'SQLSTATE='SQLSTATE
>>> "SQLSTATE=SQLSTATE"
SQLSTATE=SQLSTATE
174 *-* HighestRC = 8
>>> "8"
176 *-* exit SQLCODE
>>> "SQLCODE"
IRX0026I Error running RXQRYV1, line 176: Invalid whole number

Pedro · Posted: Wed Sep 21, 2022 1:07 am

Tell us more about your environment. That is, how do you have access to SDSNLOAD?

jaylhaskin · Posted: Wed Sep 21, 2022 1:28 am

I think I am loading sdsnload using a clist script I normally use that was given to me by another analyst. I type in db2sys and it prompts me for the subsystem name. when I provide it and hit enter it responds that it is loading the libraries for that subsystem

I used ISRDDN to check to make sure that the load libraries were allocated. It shows that DB2DT0C.DSNEXIT.B and DB2DT0C.DSNLOAD.B are both concatenated to SYS00021 ddname. When I browse the concatenation, I find the load module named DSNREXX. The status is open and active. There are many other ids and jobs that are using this library. It has always worked before today in othher scripts I have edited and used.

don.leahy · Posted: Wed Sep 21, 2022 4:25 am

Does your startup command run before of after ISPF startup? The SDSNLOAD library needs to be allocated to your session before ISPF starts. It won’t recognize a LIBDEF after startup. Unfortunately.

Pedro · Posted: Wed Sep 21, 2022 4:52 am

Based on your description (SYS00021), it seems like you are using a LIBDEF. But LIBDEF is an ISPF thing. Non-ISPF stuff like rexx and DB2 are unaware of a LIBDEF and will not look in those libraries.

You should be able to allocate the data sets to ISPLLIB before you start ISPF.

Also trying using the TSOLIB command.

jaylhaskin · Posted: Thu Sep 22, 2022 4:00 am

Well, the TSOLIB statement worked but didnt solve the problem I still had the same symptoms. I dont know why, it should have worked.

What ended up working was calling my rexx script from a separate REXX script like so:

ADDRESS ISPEXEC
"LIBDEF ISPLLIB"
"LIBDEF ISPLLIB DATASET ID('DB2DC0C.DSNEXIT.TEMP') COND STKADD"
"LIBDEF ISPLLIB DATASET ID('DB2DC0C.DSNLOAD.TEMP') COND STKADD"

call rxqryv1 "DT0C"

**********

I also had to add a parse arg statement to the top of the original REXX script to receive the variable SSID for the connect statement to use. This allowed me to get past the problem with the subcom, rxsubcom, connect issue I was having and begin to debug the rest of the script.

Thanks for the suggestions, how I solved it was by talking apart other scripts that were working and make sure I was writing and testing this script exactly the same... Don't know why I didn't see this before...

Pedro · Posted: Fri Sep 23, 2022 4:37 am