php / pecl-database-ibm_db2 Goto Github PK

Do the whole matrix: ZTS * 32/64 bit (if we still do 32-bit?) * [7.3-8.3] * VC++ version (?).

We do CI, but this just tests a PHP version in I believe non-ZTS.

Most users of this driver are likely using it on IBM i, but we only run tests in CI on Linux (and build on Windows). For things that support LUW, this is still useful, but for things that support IBM i (i.e. Doctrine) it's only useful as a smoke test due to behaviour differences.

The big problems for IBM i CI are:

• It's hard to have "disposable" IBM i environments. Does PowerVM or something have the ability to snapshot things and revert when done? (Maybe with an external SAN?)
  • We can drop the libraries that the test suite sets up initially. This would be the bare minimum.
  • It's harder if we want to have a matrix of i.e. PHP versions. Different versions means more LPARs or uninstalling and reinstalling specific versions. We could support just the latest version of PHP for an MVP.
  • The stakes are a bit higher if a malicious user runs a malicious action, because it's harder to revert as it affects a permanent environment. (Or if we use SSH, they could dump secrets...)
• It's harder to get your hands on IBM i in the first place.
  • IBM or someone else (i.e. RZKH?) may be willing to host a partition for free. It would be ideal to have a (small) partition that wouldn't be affected by other users (introducing additional state, security, and performance problems).
  • Worst case, someone can pay for a partition. Licensing and special hardware make it a little expensive, but we could run pricing from i.e. iInTheCloud, RZKH, IBM Cloud, etc. This might not be adequate if the techniques to make a pristine environment can't be done this way.
• Poor CI runner support: Most CI runners for GH Actions, GL, etc. are written in Go, and Go doesn't support PASE yet. There was an experimental port of Go 1.15, but it isn't actively supported. IBM is currently prioritizing Rust right now.
  • We could deploy something like Jenkins which uses i.e. a Java based runner, but we won't be able to use Actions. (That's probably not a big ask since IBM i would require different steps for running anyways.) We'd also have to run a Jenkins instance.
  • We could do everything over SSH, logging in as an low-privilege user (though that'd make installing things in the environment complicated), putting the credentials into secrets.

There also may be value in the (rare) case of LUW client connecting to IBM i serverr.

This issue also affects other things too like PDO_IBM, XMLSERVICE, and the Doctrine support for Db2i. (Poor CI availability is why Doctrine upstream was a bit cold to IBM i historically.)

(Writing it in here instead of bugs.php primarily so we can get the feel for GH issues for PHP stuff.)

The fact this API takes a symbol name (which it goes off into the symbol table to frob) gives it really confusing semantics (when exactly is the bind applied? what happens when the scope of bind and exec are different?), especially when classes are involved, and I suspect it's the root cause of many bizarre hard to explain (let alone reproduce) issues we encounter. We've also been special-cased by opcache because of this.

What we should be doing is either change the old API (if it can be done w/o a BC break, or if a BC break is acceptable), or a new API that takes a reference instead. I suspect we need to alter the bind handling a little so it can work with both semantics.

I think this might be preferable since we can't get everyone to use ODBC/PDO_IBM and this would be a smaller change for users than switching to those.

https://windows.php.net/downloads/pecl/releases/ibm_db2/2.1.5/logs/

PHP Version: 7.2.15
Module Version: 2.0.6-zs1

On SQL inserts and updates string fields are automatically trimmed if over the field length. This is not the case via QShell though. This is using normal ASCII characters. No UTF-8 characters used. Any extra characters are discarded (ASCII or UTF-8) no errors or warnings produced.

I have the same script running via the HTTP server and QShell using the php-cli.

PHP and all module ini files are the same when going through the HTTP server or QShell. The job is the same running the HTTP instance and QShell.

The database file is compiled using DDS and is flagged with CCSID(1208)
Field is defined as so.

CIMSTKD      140A         TEXT('Description')
                          COLHDG('Desc')   
                          VARLEN(35)               

Running via QShell has the following error.
db2_execute(): Statement Execute Failed. Value for column or variable CIMSTKD too long.

Is the autotrim even intended functionality? Logically it should fail on insert.

On a side note do you know what's happening with this bug? I reported it a while a go but nothing seems to have happened with it.
https://bugs.php.net/bug.php?id=76586

downloading ibm_db2-2.1.6.tgz ...
Starting to download ibm_db2-2.1.6.tgz (191,956 bytes)
.........................................done: 191,956 bytes
ERROR: bad md5sum for file /tmp/pear/temp/ibm_db2/php_ibm_db2.h

Just a small question regarding expected functionality. I could not find it in the docs but should the values returned from db2_fetch_assoc match the same types as the table/field definition?

E.g.
ITEMID = VARCHAR 68
ITEMSEQN = DECIMAL 5

In the associative array I would expect the ITEMID to be a string which it is however the ITEMSEQN field is also returned as a string type.

Is this how it's meant to work? I would have expected numerical fields to be returned as a int or double in PHP.

If so do you know of a way to force the types returned from db2_fetch_assoc to be the correct type?

I could manually correct it in our project however this function is used around 1000 times and the effort required would be enormous.

Logs:
=> ERROR [16/18] RUN pecl install ibm_db2 4.7s

[16/18] RUN pecl install ibm_db2:
#20 1.910 downloading ibm_db2-2.1.5.tgz ...
#20 1.912 Starting to download ibm_db2-2.1.5.tgz (196,974 bytes)
#20 1.984 .........................................done: 196,974 bytes
#20 2.231 9 source files, building
#20 2.231 running: phpize
#20 2.237 Configuring for:
#20 2.237 PHP Api Version: 20180731
#20 2.237 Zend Module Api No: 20180731
#20 2.237 Zend Extension Api No: 320180731
#20 2.529 DB2 Installation Directory? : building in /tmp/pear/temp/pear-build-defaultuserynMpFT/ibm_db2-2.1.5
#20 2.529 running: /tmp/pear/temp/ibm_db2/configure --with-php-config=/usr/local/bin/php-config --with-IBM_DB2=
#20 2.601 checking for grep that handles long lines and -e... /bin/grep
#20 2.603 checking for egrep... /bin/grep -E
#20 2.605 checking for a sed that does not truncate output... /bin/sed
#20 2.612 checking for cc... cc
#20 2.650 checking whether the C compiler works... yes
#20 2.650 checking for C compiler default output file name... a.out
#20 2.675 checking for suffix of executables...
#20 2.701 checking whether we are cross compiling... no
#20 2.716 checking for suffix of object files... o
#20 2.731 checking whether we are using the GNU C compiler... yes
#20 2.746 checking whether cc accepts -g... yes
#20 2.772 checking for cc option to accept ISO C89... none needed
#20 2.790 checking how to run the C preprocessor... cc -E
#20 2.813 checking for icc... no
#20 2.820 checking for suncc... no
#20 2.848 checking whether cc understands -c and -o together... yes
#20 2.848 checking for system library directory... lib
#20 2.857 checking if compiler supports -R... no
#20 2.882 checking if compiler supports -Wl,-rpath,... yes
#20 2.920 checking build system type... aarch64-unknown-linux-gnu
#20 2.920 checking host system type... aarch64-unknown-linux-gnu
#20 2.920 checking target system type... aarch64-unknown-linux-gnu
#20 2.946 checking for PHP prefix... /usr/local
#20 2.946 checking for PHP includes... -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib
#20 2.946 checking for PHP extension directory... /usr/local/lib/php/extensions/no-debug-non-zts-20180731
#20 2.946 checking for PHP installed headers prefix... /usr/local/include/php
#20 2.967 checking if debug is enabled... no
#20 2.986 checking if zts is enabled... no
#20 2.986 checking for re2c... re2c
#20 2.991 checking for re2c version... 2.0.3 (ok)
#20 2.991 checking for gawk... no
#20 2.992 checking for nawk... nawk
#20 2.993 checking if nawk is broken... no
#20 2.993 checking for IBM_DB2 support... yes, shared
#20 3.002 checking PHP... Detected 64-bit PHP
#20 3.002 checking IBM_DB_HOME location... /opt/ibm/clidriver
#20 3.002 checking Looking for DB2 CLI libraries... checking in /opt/ibm/clidriver...
#20 3.002 checking in /opt/ibm/clidriver/lib64...
#20 3.002 checking in /opt/ibm/clidriver/lib... found
#20 3.002 checking for DB2 CLI include files in default path... checking in /opt/ibm/clidriver... found in /opt/ibm/clidriver
#20 3.012 checking for ld used by cc... /usr/bin/ld
#20 3.014 checking if the linker (/usr/bin/ld) is GNU ld... yes
#20 3.014 checking for /usr/bin/ld option to reload object files... -r
#20 3.016 checking for BSD-compatible nm... /usr/bin/nm -B
#20 3.016 checking whether ln -s works... yes
#20 3.017 checking how to recognize dependent libraries... pass_all
#20 3.088 checking for ANSI C header files... yes
#20 3.107 checking for sys/types.h... yes
#20 3.128 checking for sys/stat.h... yes
#20 3.150 checking for stdlib.h... yes
#20 3.174 checking for string.h... yes
#20 3.197 checking for memory.h... yes
#20 3.220 checking for strings.h... yes
#20 3.243 checking for inttypes.h... yes
#20 3.266 checking for stdint.h... yes
#20 3.291 checking for unistd.h... yes
#20 3.314 checking dlfcn.h usability... yes
#20 3.322 checking dlfcn.h presence... yes
#20 3.322 checking for dlfcn.h... yes
#20 3.326 checking the maximum length of command line arguments... 1572864
#20 3.377 checking command to parse /usr/bin/nm -B output from cc object... ok
#20 3.381 checking for objdir... .libs
#20 3.381 checking for ar... ar
#20 3.381 checking for ranlib... ranlib
#20 3.381 checking for strip... strip
#20 3.435 checking if cc supports -fno-rtti -fno-exceptions... no
#20 3.436 checking for cc option to produce PIC... -fPIC
#20 3.453 checking if cc PIC flag -fPIC works... yes
#20 3.499 checking if cc static flag -static works... yes
#20 3.519 checking if cc supports -c -o file.o... yes
#20 3.528 checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes
#20 3.548 checking whether -lc should be explicitly linked in... no
#20 3.558 checking dynamic linker characteristics... GNU/Linux ld.so
#20 3.558 checking how to hardcode library paths into programs... immediate
#20 3.560 checking whether stripping libraries is possible... yes
#20 3.561 checking if libtool supports shared libraries... yes
#20 3.561 checking whether to build shared libraries... yes
#20 3.561 checking whether to build static libraries... no
#20 3.663
#20 3.663 creating libtool
#20 3.676 appending configuration tag "CXX" to libtool
#20 3.722 configure: creating ./config.status
#20 3.755 config.status: creating config.h
#20 3.777 running: make
#20 3.779 /bin/bash /tmp/pear/temp/pear-build-defaultuserynMpFT/ibm_db2-2.1.5/libtool --mode=compile cc -I. -I/tmp/pear/temp/ibm_db2 -DPHP_ATOM_INC -I/tmp/pear/temp/pear-build-defaultuserynMpFT/ibm_db2-2.1.5/include -I/tmp/pear/temp/pear-build-defaultuserynMpFT/ibm_db2-2.1.5/main -I/tmp/pear/temp/ibm_db2 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib -I/opt/ibm/clidriver/include -DHAVE_CONFIG_H -g -O2 -c /tmp/pear/temp/ibm_db2/ibm_db2.c -o ibm_db2.lo
#20 3.825 mkdir .libs
#20 3.827 cc -I. -I/tmp/pear/temp/ibm_db2 -DPHP_ATOM_INC -I/tmp/pear/temp/pear-build-defaultuserynMpFT/ibm_db2-2.1.5/include -I/tmp/pear/temp/pear-build-defaultuserynMpFT/ibm_db2-2.1.5/main -I/tmp/pear/temp/ibm_db2 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib -I/opt/ibm/clidriver/include -DHAVE_CONFIG_H -g -O2 -c /tmp/pear/temp/ibm_db2/ibm_db2.c -fPIC -DPIC -o .libs/ibm_db2.o
#20 3.876 In file included from /opt/ibm/clidriver/include/sqlcli1.h:45,
#20 3.876 from /tmp/pear/temp/ibm_db2/php_ibm_db2.h:45,
#20 3.876 from /tmp/pear/temp/ibm_db2/ibm_db2.c:35:
#20 3.876 /opt/ibm/clidriver/include/sqlcli.h:876: warning: "ODBCVER" redefined
#20 3.876 876 | #define ODBCVER 0x0380
#20 3.876 |
#20 3.876 In file included from /usr/local/include/php/Zend/zend_config.h:1,
#20 3.876 from /usr/local/include/php/Zend/zend_portability.h:43,
#20 3.876 from /usr/local/include/php/Zend/zend_types.h:25,
#20 3.876 from /usr/local/include/php/Zend/zend.h:27,
#20 3.876 from /usr/local/include/php/main/php.h:33,
#20 3.876 from /tmp/pear/temp/ibm_db2/ibm_db2.c:31:
#20 3.876 /usr/local/include/php/main/../main/php_config.h:2260: note: this is the location of the previous definition
#20 3.876 2260 | #define ODBCVER 0x0350
#20 3.876 |
#20 4.583 /bin/bash /tmp/pear/temp/pear-build-defaultuserynMpFT/ibm_db2-2.1.5/libtool --mode=link cc -DPHP_ATOM_INC -I/tmp/pear/temp/pear-build-defaultuserynMpFT/ibm_db2-2.1.5/include -I/tmp/pear/temp/pear-build-defaultuserynMpFT/ibm_db2-2.1.5/main -I/tmp/pear/temp/ibm_db2 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib -I/opt/ibm/clidriver/include -DHAVE_CONFIG_H -g -O2 -o ibm_db2.la -export-dynamic -avoid-version -prefer-pic -module -rpath /tmp/pear/temp/pear-build-defaultuserynMpFT/ibm_db2-2.1.5/modules ibm_db2.lo -Wl,-rpath,/opt/ibm/clidriver/lib/ -L/opt/ibm/clidriver/lib/ -ldb2
#20 4.637 cc -shared .libs/ibm_db2.o -L/opt/ibm/clidriver/lib/ -ldb2 -Wl,-rpath -Wl,/opt/ibm/clidriver/lib/ -Wl,-soname -Wl,ibm_db2.so -o .libs/ibm_db2.so
#20 4.640 /usr/bin/ld: skipping incompatible /opt/ibm/clidriver/lib//libdb2.so when searching for -ldb2
#20 4.640 /usr/bin/ld: cannot find -ldb2
#20 4.640 /usr/bin/ld: skipping incompatible /opt/ibm/clidriver/lib//libdb2.so when searching for -ldb2
#20 4.641 collect2: error: ld returned 1 exit status
#20 4.641 make: *** [Makefile:199: ibm_db2.la] Error 1
#20 4.645 ERROR: `make' failed

executor failed running [/bin/sh -c pecl install ibm_db2]: exit code: 1
ERROR: Service 'main_php' failed to build : Build failed

On IBM i:

=====================================================================
TEST RESULT SUMMARY
---------------------------------------------------------------------
Exts skipped    :     0
Exts tested     :    14
---------------------------------------------------------------------

Number of tests :   225               159
Tests skipped   :    66 ( 29.3%) --------
Tests warned    :     0 (  0.0%) (  0.0%)
Tests failed    :    10 (  4.4%) (  6.3%)
Tests passed    :   149 ( 66.2%) ( 93.7%)
---------------------------------------------------------------------
Time taken      :    50 seconds
=====================================================================

=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
IBM-DB2: db2_tables() - Play with table objects [tests/test_V6_066_TableObjects.phpt]
IBM-DB2: PECL bug 10931 -- no result for db2_columns with lowercase table name [tests/test_V6_10931_LcaseTableName.phpt]
IBM-DB2: db2_statistics(): testing indexes [tests/test_V6_197_StatisticsIndexes.phpt]
IBM-DB2: db2_statistics(): testing indexes [tests/test_V6_197_StatisticsIndexes_with_lib_1028_issue.phpt]
IBM-DB2: 1.9.7 - IBM i force all connect to pconnect (operator issue) [tests/test_V6_ini_i5_all_pconnect.phpt]
IBM-DB2: 1.9.7 - IBM i check pconnect (alternative LUW ping) [tests/test_V6_ini_i5_check_pconnect.phpt]
IBM-DB2: 1.9.7 - IBM i security guard profile (customer application issue) [tests/test_V6_ini_i5_guard_profile.phpt]
IBM-DB2: 1.9.7 - IBM i ignore user profile (operator no QSQSRVR jobs) [tests/test_V6_ini_i5_ignore_userid.phpt]
IBM-DB2: 1.9.7 - IBM i max use pconnect (operator issue) [tests/test_V6_ini_i5_max_pconnect.phpt]
IBM-DB2: 1.9.7 - IBM i change QSQSRVR subsystem ccsid 1208 (operator issue) [tests/test_V6_ini_i5_servermode_subsystem.phpt]
=====================================================================

Most of these are deprecation messages from passing null like Deprecated: db2_columns(): Passing null to parameter #2 ($qualifier) of type ?string is deprecated in /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_10931_LcaseTableName.php on line 15 like so:

$ for i in tests/*.diff; do echo " ** $i **"; cat $i; echo; done
 ** tests/test_V6_066_TableObjects.diff **
001+ Deprecated: db2_tables(): Passing null to parameter #2 ($qualifier) of type ?string is deprecated in /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_066_TableObjects.php on line 7
002+ Schema:  CALVIN
003+ Name:    ANIMALS
004+ Type:    TABLE
005+ Remarks: 
006+ 
     Schema:  %s
     Name:    ANIMALS
     Type:    TABLE
--

 ** tests/test_V6_10931_LcaseTableName.diff **
001+ Deprecated: db2_columns(): Passing null to parameter #2 ($qualifier) of type ?string is deprecated in /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_10931_LcaseTableName.php on line 15
     array(18) {
       ["TABLE_CAT"]=>
       string(%d) "%s"
--

 ** tests/test_V6_197_StatisticsIndexes.diff **
     Test first index table:
002+ 
003+ Deprecated: db2_statistics(): Passing null to parameter #2 ($qualifier) of type ?string is deprecated in /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_197_StatisticsIndexes.php on line 20
004+ 
005+ Deprecated: db2_statistics(): Passing null to parameter #3 ($schema) of type ?string is deprecated in /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_197_StatisticsIndexes.php on line 20
     INDEX_TEST
     1
     INDEX1
     ID
     Test second index table:
011+ 
012+ Deprecated: db2_statistics(): Passing null to parameter #2 ($qualifier) of type ?string is deprecated in /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_197_StatisticsIndexes.php on line 33
013+ 
014+ Deprecated: db2_statistics(): Passing null to parameter #3 ($schema) of type ?string is deprecated in /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_197_StatisticsIndexes.php on line 33
     INDEX_TEST2
     1
     INDEX2
     DATA
     Test non-existent table:
020+ 
021+ Deprecated: db2_statistics(): Passing null to parameter #2 ($qualifier) of type ?string is deprecated in /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_197_StatisticsIndexes.php on line 41
022+ 
023+ Deprecated: db2_statistics(): Passing null to parameter #3 ($schema) of type ?string is deprecated in /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_197_StatisticsIndexes.php on line 41
     Empty

 ** tests/test_V6_197_StatisticsIndexes_with_lib_1028_issue.diff **
     Test first index table:
002+ 
003+ Deprecated: db2_statistics(): Passing null to parameter #2 ($qualifier) of type ?string is deprecated in /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_197_StatisticsIndexes_with_lib_1028_issue.php on line 14
     INDEX_TEST
     1
     INDEX1
     ID
     Test second index table:
009+ 
010+ Deprecated: db2_statistics(): Passing null to parameter #2 ($qualifier) of type ?string is deprecated in /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_197_StatisticsIndexes_with_lib_1028_issue.php on line 27
     INDEX_TEST2
     1
     INDEX2
     DATA
     Test non-existent table:
016+ 
017+ Deprecated: db2_statistics(): Passing null to parameter #2 ($qualifier) of type ?string is deprecated in /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_197_StatisticsIndexes_with_lib_1028_issue.php on line 35
     Empty

 ** tests/test_V6_ini_i5_all_pconnect.diff **
     %s
     %s
003- success
     %s
     %s
006- success
007- success
005+   thrown in /home/calvin/src/pecl-database-ibm_db2/tests/xmlservice.inc on line 72

 ** tests/test_V6_ini_i5_check_pconnect.diff **
     (IBM_DB_i5_check_pconnect=-42)
002+ 
     %s
     %s
004- success
005- (IBM_DB_i5_check_pconnect=4)
     %s
007- success
006+ #1 {main}
007+   thrown in /home/calvin/src/pecl-database-ibm_db2/tests/xmlservice.inc on line 72

 ** tests/test_V6_ini_i5_guard_profile.diff **
001- key1 %s
002- key2 %s
003- key3 %s
004- success
005- success
006- success
001+ Fatal error: Uncaught Error: Call to undefined function simplexml_load_string() in /home/calvin/src/pecl-database-ibm_db2/tests/xmlservice.inc:72
002+ Stack trace:
003+ #0 /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_ini_i5_guard_profile.php(9): xmlservice_diag_jobinfo('<?xml version='...')
004+ #1 {main}
005+   thrown in /home/calvin/src/pecl-database-ibm_db2/tests/xmlservice.inc on line 72

 ** tests/test_V6_ini_i5_ignore_userid.diff **
     %s
     %s
003- success
004- success
005- success
     %s
     %s
008- success
009- success
010- success
011- success
005+   thrown in /home/calvin/src/pecl-database-ibm_db2/tests/xmlservice.inc on line 72

 ** tests/test_V6_ini_i5_max_pconnect.diff **
     %s
     %s
003- success
     %s
005- success
004+ #1 {main}
005+   thrown in /home/calvin/src/pecl-database-ibm_db2/tests/xmlservice.inc on line 72

 ** tests/test_V6_ini_i5_servermode_subsystem.diff **
     %s
002- success
002+ Stack trace:
003+ #0 /home/calvin/src/pecl-database-ibm_db2/tests/test_V6_ini_i5_servermode_subsystem.php(18): xmlservice_diag_jobinfo('<?xml version='...')
004+ #1 {main}
005+   thrown in /home/calvin/src/pecl-database-ibm_db2/tests/xmlservice.inc on line 72

(Some I haven't set up on this system, like the xmlservice profile swap test)

If the setup-php action supports 8.3, I'm also willing to add it early.

Adapted from a Slack conversation, for public consumption:

we're actually getting a chance to diagnose check_pconnect https://github.com/php/pecl-database-ibm_db2/blob/master/ibm_db2.c#L2395-L2433 in the field and the lab, and we're getting some fun results. my lab environment has the following behaviour where:
=4 where it does a full exec works for determining if the persistent connection is alive
=3 where it just creates a statement handle does not
=2 where it gets a string attribute (DB type) does
=1 where it gets a bool attribute (autocommit) does not
and my methodology is "kill DB server job".
as for the behaviour diff, i wonder if this is possibly rooted in SQL/CLI server changes? these used to work. i.e. =3 has handles able to be created locally and remotely creating them is deferred, and =1 autocommit info is cached

(There is also a double-free I had mentioned, but this seems to be more in the PHP built-in web server. Eep!)

@kadler mentioned:

So CLI operates in the PHP job. Only if it needs to access SQL or call an SQL API to set something will it jump over to the QSQSRVR job.
It looks like SQLGetConnectAttr does do some SQ work before handling the SQL_ATTR_AUTOCOMMIT (which is an internal CLI attribute), but I'm not sure if that would bail if the QSQSRVR job is gone (edited)
SQLGetInfo does have a check after parameter validation if it knows the job is gone that it will give an error, but it doesn't check the status at that point, just the cached info.

The "throw things at a wall and see what sticks" nature of the current implementation was mentioned. I don't know if these originally worked, and the behaviours have changed, or if they always were the same and a variety of strategies were considered and implemented.

Later, he proposed SQL_CONNECTION_JOB_NAME and calling QUSRJOBI to fetch status of the job, instead of relying on SQL (which may have side effects). I worry if this would only really work for local instances though.

This is also pretty i-specific, but the LUW/z path is using the ping attribute anyways. It'd be nice if we had a CONNECTION_DEAD, but that would require a new version of i/TRs.

• Convert 0/1 only options to bools
• Make integer options have proper constants, use those in documentation
• Make some options no longer i specific if they work everywhere (i.e. log verbose)
  • Some are i specific but can be useful if connecting from LUW, identify what works in LUW to i
  • Rename when applicable, can we still check for back-compat?
• Rename some confusing options (i.e. ignore user ID actually runs Db2 server job in-process)

PHP has semi-deprecated resources. They aren't going away, but they aren't recommended anymore, and built-in extensions are being converted.

The main benefit would be being able to use PHP's type system to distinguish between i.e. connections and statements, and declare methods on them (though the old functions would remain for compatibility). I suspect lifetimes would be easier to manage too.

This would be a breaking change for consumers like i.e. the PHP toolkit, that determine if something is ibm_db2 by using resource functions.

Either run the Linux Docker container, or set up the Windows version of Db2. (That seems pretty annoying to do in an automated fashion...)

Low priority because building is most important, and LUW stuff should be consistent across platforms.

followed below steps from https://github.com/php/pecl-database-ibm_db2#how-to-build-from-source-code-in-linux-or-mac

Use the commands included in the source code:
download Source code from https://pecl.php.net/package/ibm_db2
 a) Extract the source archive
 b) Run the following commands from the extracted directory:
      $ phpize --clean
      $ phpize
      $ ./configure --with-IBM_DB2=/home/user/clidriver
      $ make
      $ make install

failed. output from make is in attached file
file.txt

Someone requested support for this, I believe it's in 7.4+.

Roadmap:

• Shims to ensure it still builds on older versions of the OS
• Identify if LUW supports it
• Add support
• Tests, detect if we're on on i 7.4+

A customer informed us of an issue where db2_pconnect doesn't seem to verify the password after the persistent connection has been established, and they were concerned about this behaviour.

Reproduction:

<?php


// test pconnect

$start = microtime(true);

echo "about to connect<BR>";
// do this the first time
$conn = db2_pconnect('*LOCAL', 'user', 'good password');
// then the second time
//$conn = db2_pconnect('*LOCAL', 'user', 'bad password');
var_dump($conn);
echo "any errors: " . db2_conn_errormsg() . '<BR>';

//$sql = "select * from qiws.qcustcdt where LSTNAM = 'Henning'";//?";

$sql = "select * from qiws.qcustcdt where LSTNAM = ?";//?";

echo "<BR>about to prepare<BR>";
$stmt = db2_prepare($conn, $sql);
var_dump($stmt);
echo "any errors: " . db2_stmt_errormsg() . '<BR>';

$lstnam = 'Henning';


echo "<BR>about to bind<BR>";
$result = db2_bind_param($stmt, 1, 'lstnam', DB2_PARAM_IN);//conn, $sql);
var_dump($result);
echo "any errors: " . db2_stmt_errormsg() . '<BR>';



echo "<BR>about to exec<BR>";
$result = db2_execute($stmt);
var_dump($result);
echo "any errors: " . db2_stmt_errormsg() . '<BR>';

echo "<BR>about to fetch<BR>";
$row = db2_fetch_assoc($stmt);
var_dump($row);
echo "any errors: " . db2_stmt_errormsg() . '<BR>';

$stmt = "";

$duration = microtime(true) - $start;

echo "<BR>Duration: {$duration} seconds.<BR>";

Alan looked into this and noted only the UID and database are used in the hash for a persistent connection, and connections function . However, specifying i5_check_pconnect to 4 does force the connection to fail as the user thinks it should. The path for level 4 involves executing a dummy statement (previous levels merely query the DB or create a handle). Not sure why it'd fail the connection only then; I would think that a query would behave the same as it would later in the program. We're proposing setting it to 4 as a workaround for that customer and see if it's solving it.

I'd like to know if this is something worth fixing (i.e. is it actually safe to assume, and it's NOTABUG?); two workarounds I can think of off-hand are either store a (hashed) password as part of the persistent connection hash, or eat the costs of connection init/teardown for a persistent connection before reusing one (as a level 5?).