App Server Connection Pooling Causing RSP009 Subcode 66

, , , , ,
1

In our shop, we have java applications running in WebSphere talking to CONNX to retreieve data from Adabas. The java application is configured (in WebSphere) to validate their DB connection before sending commands to the CONNX JDBC Server. Connection pooling is used in WebSphere.

The problem happens when WebSphere is recycled and that may not recycle the DB connection pool that WebSphere maintains.

When that happens, the application receives a “STATEMENT NOT ACTIVE” error with its Adabas call and I always see a rsp 009 subcode 66 in the CONNX JDBC Server log.

It seems that when the connection pool associated to WebSphere is not refreshed then the application results in using connection that no longer have a corresponding UQE in Adabas. The connection is still deemed as validate on the app server side.

Can you describe who issues the OP command and with connection pooling on the app server, who checks to make sure a UQE still existed in Adabas and makes the decision on when OP needs to be reissued? If reissued is needed, would I see a rsp 009 subcode 66 in the JDBC server log? Should the front end see any error?

We have connectionpooling turned off on the CONNX JDBC and the ACE side. We have REISSUEOP=1 set in both CONNX JDBC and ACE parms.

I appreciate any comment or suggestion from you.

Many thanks in advance.

Min

2

This sounds like something that development could be interested in.

May I suggest you contacting your local SAG Support on this one?

Thanks
Rick

3

Rick,

I will open a ticket with SAG Support.

Thanks,
Min

4

Rick,

I have opened a ticket on this with SAG Support. R&D will adjust the SQL gateway to re-issue the OP when it sees a response code 9 subcode 66.

But aside from that I am really trying to understand why the discrepancy. We are seeing a volume of response code 9 subcode 66 in one CONNX instance but not the other. The one CONNX installation that does not get the error has a CONNX JDBC Server communicating with 1 CONNX listener on the mainframe. The CONNX instance that does get an incredible amount of response code 9 subcode 66 has 1 CONNX JDBC Server communicating with 2 separate CONNX listeners on the mainframe. Each listener talks to a separate Adabas DB and each listener runs on a different mainframe region with different port number.

Could the sharing of the JDBC server be the cause here? Is this a good practice to share jdbc server across listener?

Please share your thoughts.

Many thanks,
Min

5

Technically -
Multiple JDBC servers should be able to communicate with a common Data Server (Listener)

I would suggest giving this configuration description to development for discussion;
it sounds as if the separate sessions are possibly being confused or mixed.

ADARSP=9/66
An Adabas session with OPENRQ=YES was active and
the user issued an Adabas command without having issued an OP command.