db2_connect & db2_pconnect problem

[aseiden]

You are mixing up your db2_connect and i5_connect. They are not related at all if you are using the original Easycom toolkit, which you seems to be doing. The example code you showed is i5_connect, not db2_connect.

To find the database jobs with current user, you need WRKACTJOB SBS(QSYSWRK) and then look in the "current user" column.

[ahaithcox]

Yeah, sorry about the mix-up. I was talking both about i5 and db2, but showed only the i5 connect code. Both scripts are exactly the same except for hostname and function name.
I only found two instances of the user I'm using to connect with in QSYSWRK and they were not errors. I've not had any problems since I last switched to db2_connect instead of _pconnect and my i5_connect is working this morning as well. There are 0 instances of the connect script user in QSYSWRK this morning. I guess because _connect does not maintain the connection job where as _pconnect would? I'll just have to wait until the next failure and check again to see if I can then find a definitive error.

Thanks again,
Adam

[shlomov]

http://www-304.ibm.com/support/docview. ... wg21476411

[ahaithcox]

I've tried again to revisit enabling db2_pconnect in our scripts which has caused several failures. I've had to revert back to db2_connect for all. I had the opportunity this morning to examine the QSYSWRK subsytem on a server that was failing when calling db2_pconnect. I found the job with the user that's used to make the connection (ZENDDB2USR), but there weren't any messages. I did notice a object lock on the user profile, but I'm assuming that's expected:

Code: Select all

                             Object                      Member  ASP   
Opt  Object      Library     Type       Lock     Status  Locks   Device
     ZENDDB2USR  QSYS        *USRPRF    *SHRRD    HELD                 
                                        *SHRRD    HELD                 
                                        *SHRRD    HELD                 
                                                                       


Ending the job did not resolve the problem and I didn't know where else to look. I changed the connection script to use db2_connect instead and it immediately starting working. I'm so frustrated with this. We can't utilize the optimization of persistent connections if they fail.

Power 7 box: V7R1M000
Model: E4B
Zend Server CE: ZS5.5.0
PHP: 5.3.8

[aseiden]

Adam,

Is the error still "Connection to relational database S1044BCP does not exist." ?

Does your db2_pconnect() return a value of false? If so, can you get any detailed errors with db2_conn_error() and db2_conn_errormsg()?

One more test. Instead of using *LOCAL as the database name, try *LOCAL-*DEBUG. Yes, just like that, '*LOCAL-*DEBUG'. This will cause the QSQSRVR job to send a message to QSYSOPR so that you can track down the running QSQSRVR job. DSPMSG QSYSOPR, F9 to find the job, etc. Look at the QSQ joblog to find clues.

Keep us posted, please.

Alan

[ahaithcox]

Thanks for the quick reply Alan. I did not step through the connection as it was on a remote box and I've not yet been successful at using xdebug remotely. Anyway, I've re-enabled pconnect and changed the db name here on our development server to try and catch the error again. When I do, I'll run through the tests you have listed. I'd really like to get to the bottom of this as I'm sure you would as well. Thanks for the support, I'll keep you informed.

[aseiden]

Adam, sounds good. One more question: you're not using pclose(), are you?

Alan

[ahaithcox]

Nope, not using pclose(). Seems that I had read somewhere long ago there was a performance problem with that. Can't remember.

BTW... when I tried using "*LOCAL-*DEBUG", I got the following error:

Relational database *LOCAL-*DEBUG not in relational database directory.

I switched back to just *LOCAL.

[aseiden]

Yes, pclose() hurts performance because it ends persistent connections (that will have to be restarted later).

If you get the message "Relational database *LOCAL-*DEBUG not in relational database directory" then your db2 driver may be old--which could be part of the problem.

Which version of Zend Server do you have?
http://www.alanseiden.com/2012/04/18/wh ... -for-ibmi/

Alan

[aseiden]

Adam,

While you're at it, please check the version of your ibm_db2 extension:

Code: Select all

call qp2term
/usr/local/zendsvr/bin/php-cli --re ibm_db2 | grep version


The above command should return something like:
Extension [ <persistent> extension #33 ibm_db2 version 1.9.0 ]

or whatever the version is. In this example the version was 1.9.0.

Alan