Highlights: Still Running IBM Informix 12.10?

Welcome to the International Informix Users Group (IIUG) Insider! Designed for IIUG members and Informix user group leaders, this publication contains timely and relevant information for the Informix community.

Editorial

Happy Halloween to all and Feliz dia de los muertos to our Mexican users. 

By the time this issue will be published the nomination for the IIUG Board of Directors 2027-2028 will be closed. We will announce the candidates on November 16th. If there are more candidates than board positions, the board elections will start on November 23rd. Since the Insider is a monthly news letter, you will be notified by email.

Stay tuned.

Gary Ben-Israel
IIUG Insider Editor 
IIUG Board of Directors 
gary@iiug.org  

 

 

Highlights

Here’s What You Need to Know About Extended Support 

IBM Informix 12.10 transitioned to Extended Support on May 1, 2026. While Extended Support provides customers with additional time to plan their upgrades, it comes with important changes to support coverage, defect remediation, and security maintenance. 

What happens if you encounter a critical production issue? Will new security fixes be available? Does purchasing Extended Support later extend your coverage? And what if you only need a few months of support before completing your upgrade? 

The latest article, “IBM Informix 12.10: Understanding the Transition to Extended Support and Planning Your Next Steps,” addresses these questions and explains why moving to Informix 14.10 or 15.0 is the recommended long-term approach. 

If your organization is still running Informix 12.10, this is a good time to review your support coverage and establish a clear upgrade plan. 

Read the full article: https://community.ibm.com/community/user/blogs/anup-nair/2026/10/20/clarifyinformix1210extendedsupport 

Thanks & Regards. 

 

Anup Nair
IBM

 

 

 

 

Which Informix Build Should You Run?

Run the latest Mod Pack or Fix Pack for your release. If you hit an urgent, core issue that isn’t fixed in a released pack, but support identifies it as fixed in an available Cumulative Special Build (CSB), apply that CSB. If support identifies your issue is already fixed in a released pack, apply that pack instead.

What is in each of the three release types?

• Mod Packs (V15 only) bring significant new features plus fixes for Known Issues (KIs).
• Fix Packs deliver fixes only.
• CSBs provide fixes for urgent, core KIs and security fixes and are designed to make these fixes available to customers faster while maintaining the same reliability of a Mod or Fix Pack. CSBs are built on the latest released pack for the current code. (Backporting fixes into older packs happens only by exception).

     All three are cumulative, so the latest one for your release contains every fix previously delivered for it.

Mod Packs, Fix Packs, and CSBs are available via Fix Central for IBM Informix and ESD for HCL Informix.

CSBs are not provided for defects already fixed in a released pack. IBM publishes a technote, Informix Cumulative Special Builds, listing the KIs fixed in each CSB , so check it before you open a case.

The takeaway

Stay current on packs, and treat a CSB as a targeted fix, not a baseline.

For more details see Support policy statement for Informix Server for Linux, UNIX and Windows Mod Packs, Fix Packs, Cumulative Special Builds, and IBM Expertise Connect

 

Karen Qualley 
HCL

 

 

Informix PDO Driver in RHEL 10 / Rocky Linux 10

16 Oct 2026 · @Vicente Salvador 

The PDO_INFORMIX driver still works on RHEL 10 and Rocky Linux 10, but the latest PECL release (1.3.7) no longer compiles out of the box: you need three small source fixes before make succeeds. This post updates my 2019 guide, PHP Informix PDO Driver in RHEL 8, for the new platform. The goal is the same: a LAIP stack (Linux, Apache, Informix, PHP). 

What changed since RHEL 8: 

• PHP 8.3 is the default version in the EL10 AppStream repository. 

• GCC 14 treats incompatible pointer types as errors instead of warnings. This is what breaks the PDO_INFORMIX 1.3.7 build. 

• ncurses-compat-libs (needed by dbaccess and other CSDK tools) is no longer in the base OS. It now lives in EPEL 10 

• Informix Client SDK 15.0 is the current client, matching Informix 15. Use the client for your Informix version 

• PDO_INFORMIX 1.3.7, released 2025-01-29, is still the latest version on PECL. 

Install the LAMP stack 

Starting from a minimal Rocky Linux 10 (or RHEL 10) installation, install Apache, PHP 8.3 and the build tools in one go: 

dnf -y install httpd php php-cli php-fpm php-pdo php-mbstring php-xml \ 

               php-gd php-zip php-bcmath php-devel gcc make autoconf 

As in RHEL 9, PHP runs as a separate php-fpm daemon. Enable and start both services: 

systemctl enable –now httpd 

systemctl enable –now php-fpm 

Open the firewall for HTTP and HTTPS: 

firewall-cmd –zone=public –add-service=http –permanent 

firewall-cmd –zone=public –add-service=https –permanent 

firewall-cmd –reload 

Check the PHP version; it should report 8.3.x: 

php -v 

Install the Informix Client SDK 

The CSDK tools still link against libncurses.so.5. RHEL 10 dropped the compat libraries from the base OS, so enable EPEL (and CRB) first and install them from there: 

dnf -y install epel-release 

dnf config-manager –set-enabled crb 

dnf -y install ncurses-compat-libs 

On RHEL proper, install the EPEL release RPM from the Fedora project instead of epel-release, and enable CRB with subscription-manager repos. 

Download the Informix Client SDK 15.0 for Linux x86_64 (at the time of writing, ibm.csdk.15.0.0.2.Linux.64.x86_64.tar). Copy it to the server, extract it in a temporary folder and run the installer as root: 

tar xvf ibm.csdk.15.0.0.2.Linux.64.x86_64.tar 

./installclientsdk 

The rest of this post assumes the CSDK is in /opt/IBM/Informix_Client-SDK. If you install it elsewhere, change that path in the following steps. 

Optionally, register the CSDK libraries with the dynamic linker. This saves you from setting LD_LIBRARY_PATH for command-line PHP scripts: 

export INFORMIXDIR=/opt/IBM/Informix_Client-SDK 

cat > /etc/ld.so.conf.d/informix.conf <<EOF 

$INFORMIXDIR/lib 

$INFORMIXDIR/lib/cli 

$INFORMIXDIR/lib/esql 

EOF 

ldconfig 

Why PDO_INFORMIX 1.3.7 fails to buildRunning the usual phpize && ./configure && make on Rocky Linux 10 stops with type errors. None of them are new bugs in Informix or PHP: the code relied on implicit pointer conversions that older compilers only warned about, and GCC 14 now rejects them. 

 

File	Line	Error	Cause
informix_driver.c	93	passing argument 2 of pdo_parse_params from incompatible pointer type	Since PHP 8.1, pdo_parse_params() takes a zend_string *. The code casts the SQL string to char * before passing it.
informix_statement.c	102–103	initialization of ssize_t (*)(…) from incompatible pointer type	Since PHP 7.4, stream read/write callbacks must return ssize_t. The LOB stream functions still return size_t.
informix_statement.c	420	comparison between pointer and zero character constant (warning)	Z_STRVAL_P(parameter) == ‘\0’ compares the pointer, not the first character, so the empty-string test never matches. A real bug.

You could hide the first two with CFLAGS=”-Wno-error=incompatible-pointer-types”, and the driver would likely work. I don’t recommend it: fixing the source takes three commands and keeps the compiler on your side for the next upgrade. 

Patch, build and install the driver 

Download and extract the source as root: 

wget https://pecl.php.net/get/PDO_INFORMIX-1.3.7.tgz 

tar xzvf PDO_INFORMIX-1.3.7.tgz 

cd PDO_INFORMIX-1.3.7 

Apply the three fixes: 

# 1. Pass the zend_string to pdo_parse_params() without a char* cast (PHP 8.1+ branch) 

sed -i ‘s/pdo_parse_params(stmt, (char \*) stmt_string,$/pdo_parse_params(stmt, stmt_string,/’ informix_driver.c 

 

# 2. LOB stream read/write callbacks must return ssize_t (PHP 7.4+) 

sed -i -E ‘s/^(static[[:space:]]+)?size_t([[:space:]]+lob_stream_(read|write)[[:space:]]*\()/\1ssize_t\2/’ informix_statement.c 

 

# 3. Test for an empty string by length, not by comparing the pointer 

sed -i ‘s/Z_STRVAL_P(parameter) == .\\0./Z_STRLEN_P(parameter) == 0/’ informix_statement.c 

Check that each fix landed before compiling. Every lob_stream_read and lob_stream_write declaration must now say ssize_t, including any forward declaration near the top of the file: 

grep -n ‘pdo_parse_params’ informix_driver.c 

grep -n ‘lob_stream_read\|lob_stream_write’ informix_statement.c 

grep -n ‘Z_STRLEN_P(parameter) == 0’ informix_statement.c 

In 1.3.7 the functions are defined without static. Before the fix: 

size_t lob_stream_read(php_stream *stream, char *buf, size_t count ) 

After the fix: 

ssize_t lob_stream_read(php_stream *stream, char *buf, size_t count ) 

The same change applies to lob_stream_write. 

If the return type sits on its own line above the function name, the second sed will not match it; edit those lines by hand. While you are there, check the error paths inside both functions: with ssize_t, PHP expects -1 on error and 0 only at end of data. 

Now build and install as usual: 

export INFORMIXDIR=/opt/IBM/Informix_Client-SDK 

phpize 

./configure –with-pdo-informix=$INFORMIXDIR 

make 

make install 

If everything worked, the module is at /usr/lib64/php/modules/pdo_informix.so. 

Configure the driver 

Enable the extension: 

cat > /etc/php.d/30-pdo_informix.ini <<EOF 

extension=pdo_informix 

EOF 

Confirm PHP loads it: 

php -m | grep -i informix 

The driver needs INFORMIXDIR at runtime, and by default php-fpm clears the environment of its workers. Edit /etc/php-fpm.d/www.conf and add or uncomment: 

clear_env = no 

Then pass the variable to the php-fpm service with a systemd override: 

systemctl edit php-fpm.service 

and enter: 

[Service] 

Environment=INFORMIXDIR=/opt/IBM/Informix_Client-SDK 

If your databases use a non-default locale, add DB_LOCALE and CLIENT_LOCALE lines the same way, or set them in the DSN as shown in the test below. Restart the service to apply everything: 

systemctl restart php-fpm 

Configure SELinux 

Rocky Linux 10 runs SELinux in enforcing mode, and by default it stops web processes from opening outbound network connections. From a browser, that shows up as Informix error -908 even though the same script works from the command line. 

In 2019 I suggested disabling SELinux. A better option is to allow just this one thing: 

setsebool -P httpd_can_network_connect 1 

This lets Apache and php-fpm connect to any port, which covers Informix listeners on non-standard ports like 9088. If you still get -908 after this, look for the denial in the audit log: 

ausearch -m avc -ts recent 

Test the driver 

Create /var/www/html/ifxtest.php, changing the connection values to match your server: 

<?php 

$dbname = ‘test_db’; 

$dbuser = ‘ifmxuser’; 

$dbpass = ‘Inf4mixPass’; 

 

$dsn  = “informix:host=192.168.1.50;service=9088;database=$dbname;server=ol_myifmxserver;protocol=onsoctcp”; 

$dsn .= “;db_locale=en_us.utf8;client_locale=en_us.utf8;EnableScrollableCursors=1”; 

 

try { 

    $conn = new PDO($dsn, $dbuser, $dbpass, [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]); 

    $stmt = $conn->prepare(“SELECT FIRST 4 * FROM test_table”); 

    $stmt->execute(); 

    echo “<pre>”; 

    var_dump($stmt->fetchAll(PDO::FETCH_ASSOC)); 

    echo “</pre>”; 

} catch (PDOException $e) { 

    echo “Connection failed: ” . htmlspecialchars($e->getMessage()); 

} 

Run it from the command line first, which rules out SELinux and php-fpm settings: 

INFORMIXDIR=/opt/IBM/Informix_Client-SDK php /var/www/html/ifxtest.php 

Then open http://<your server ip>/ifxtest.php in a browser. You should see the first rows of your table. Delete the file afterwards: it contains database credentials. 

Final notes 

Until a fixed version is released, the three sed commands above are all you need to run PDO_INFORMIX on RHEL 10, Rocky Linux 10 and AlmaLinux 10 with their stock PHP 8.3. The same fixes should also apply to PHP 8.4 from the Remi repository, but I have not tested it. 

A call for help: these fixes are small and safe, and they belong in an official 1.3.8 release so nobody has to patch the source by hand. If you can push changes to the upstream PDO_INFORMIX project, or know someone who can (the PECL page lists IBM OpenDev and Rocket Software as maintainers), please get in touch through the IIUG. I’m happy to share the patch and help test a new release. 

 

Vicente Salvador