DRDA redirection to HDR primary
Posted in 2026
Doug Lawry asked how to make a DRDA client follow an HDR primary without Connection Manager. Andreas Legner, Art Kagel and Gerd Kaluzinski discussed alternate server lists, sqlhosts groups and separate CMs for DRDA. It was concluded that DRDA does not support sqlhosts groups or CM failover itself, so a Connection Manager (or VIP/DNS) is required. Doug planned an article.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Topics: High Availability & Replication, Networking & sqlhosts Configuration, Clustering, Grid & MACH11
I was recently unable to work out how to do this directly on latest IDS 14.10. I am about to write a technical article on a work-around using Connection Manager, but that involves more effort and failure points. Does anyone know how to construct a DRDA client configuration so that it connects to whichever is the primary in an HDR pair like you can in "sqlhosts" for native TCP connections? ------------------------------ Doug Lawry Oninit Consulting ------------------------------
Hi Doug, I vaguely remember having dealt with this, my notes having things like alternateserverlist and enableAlternateServerListFirstConnect and a pointer to https://www.ibm.com/docs/en/db2/11.5.x?topic=njcshads-non-java-client-support-high-availability-connections-informix-servers Basically, I think what you're looking for is part of the DRDA protocol, so needs to be configured on that level (outside of onconfig, and outside of sqlhosts anyway). HTH, Andreas ------------------------------ Andreas Legner Informix Dev HCL Software ------------------------------
We implemented the DRDA connection using the ConnectionManager Normal Connections went on CM1, DRDA from Cognos to CM2 This works as described: Create ONSOCTCP connections on DBSERVERNAME and DRSOCTCP connections on DBSERVERALIASES Create separate Instances of the Connection Manager to handle SOCTCP (with Failover enabled) and DRDA (Failover disabled) First instance contains only the DBSERVERNAMES that are SOCTCP connections in the SERVERLIST Second instance contains only the DBSERVERALIASES that are DRDA connections in the SERVERLIST Start different instances of the CM and use these for the different connection types This configuration can be made redundant, when you define a second pair of CMs on an other server and connect the CM-Names in the Sqlhosts File of the client to a connection group (for example: g=cm and g=cmdrda) This installation worked very stable and switched normal connections and DRDA for Cognos whenever one server was down. Mit freundlichen Grüßen / Kind regards Gerd Kaluzinski Delivery Consultant Data IBM Technology Expert Labs Phone: +49 175 228 1983 IBM Deutschland GmbH Email: gerd.kaluzinski@de.ibm.com Mies-van-der-Rohe-Straße 6, 80807 München IBM Deutschland GmbH Vorsitzender des Aufsichtsrats: Ivo Körner Geschäftsführung: Wolfgang Wendt (Vorsitzender), Dr. Andreas Buchelt, Dr. Frank Kohls, Christine Rupp Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB 14562
Hi Gerd. Thanks, but the purpose of this thread is to get automated HDR fail-over redirection working without Connection Manager. ------------------------------ Doug Lawry Oninit Consulting ------------------------------
Doug: I don't know, but does the DRDA driver obey using sqlhosts groups? They can be used for failover and default to using the primary or the first listed group member if all are peers. Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------
Hi Andreas. Indeed. I was able to get that working with a Connection Manager on each IDS server as follows: <?xml version="1.0" encoding="UTF-8" standalone="no" ?> <configuration> <!-- C:\\ProgramData\\IBM\\DB2\\IBMDBCL1\\cfg\\db2dsdriver.cfg Informix cluster IBM Data Server Driver prototype configuration file Doug Lawry, Oninit Consulting, January 2026 Routes to Informix Connection Manager (CM) on either of two Informix hosts. Informix Dynamic Server (IDS) instances also run on each of those same hosts. High-availability Data Replication (HDR) maintains a passive read-only replica. Server 1 is usually the primary IDS instance and therefore more heavily loaded. Server 2 is therefore the preferred CM, so use DSN "alias2" in applications. Test with: testconn40 "database=alias2;userid=...;password=..." --> <dsncollection> <dsn alias="alias1" name="dbname" host="host1" port="9089"/> <dsn alias="alias2" name="dbname" host="host2" port="9089"/> </dsncollection> <databases> <database name="dbname" host="host1" port="9089"> <acr> <!-- Automatic client reroute --> <parameter name="enableAlternateServerListFirstConnect" value="true"/> <alternateserverlist> <server name="alias2" hostname="host2" port="9089"/> </alternateserverlist> </acr> </database> <database name="dbname" host="host2" port="9089"> <acr> <!-- Automatic client reroute --> <parameter name="enableAlternateServerListFirstConnect" value="true"/> <alternateserverlist> <server name="alias1" hostname="host1" port="9089"/> </alternateserverlist> </acr> </database> </databases> </configuration> But I can't find a way above to make it connect to whichever is the primary IDS server in an alternate server list so that we don't need Connection Managers at all, as with an sqlhosts group for standard TCP listeners. ------------------------------ Doug Lawry Oninit Consulting ------------------------------
Hi Art. IBM Data Server Driver doesn't use "sqlhosts" as it's shared with DB2. That's the problem. ------------------------------ Doug Lawry Oninit Consulting ------------------------------
Andreas: if I don't get a solution here, is this something I should open as a support request. It will be an RFE otherwise. ------------------------------ Doug Lawry Oninit Consulting ------------------------------
Hi Doug, if I'm getting you right (upon rereading), you want the connection protocol to determine whether what you're connecting to is a primary (or standard) and if not (it's a secondary), to tell the client who the primary is and possibly how/where to reach that This is not even what you'd get from sqlhosts group connects (they'd simply walk all the group members until they get connected, no matter the cluster role). In fact this is one of the CM's core functionalities, and I don't think this can/should be packed into the connection protocol, neither SQLI nor DRDA. Sorry for not seeing it this way in my previous post, and let me know if I'm again missing anything. Have a nice weekend! Andreas ------------------------------ Andreas Legner Informix Dev HCL Software ------------------------------
Hi Andreas.
Not so! We have used groups that way as long as I can remember. For example:
https://www.ibm.com/docs/en/informix-servers/14.10.0?topic=cshac-properties-connecting-high-availability-cluster-servers-through-sqlhost-file-group-entries
It's the same for other APIs that use "sqlhosts" or equivalent Windows registry constructions, though I can only find a clear statement for JDBC as above.
Will post a proof of that with "dbaccess" next time I have a test cluster running.
------------------------------
Doug Lawry
Oninit Consulting
------------------------------
Andreas: Doug is correct. Using an sqlhosts group that includes both primary and secondary servers, a connection to the group name will preferentially connect to a primary over secondaries even if the secondaries are listed earlier in the group within the sqlhosts file. It has always worked that way for native SQLI connections. Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------
You're both correct, and I stand corrected. So this is baked into the SQLI protocol which, of course, we fully own and have control over and which we equipped to our user's needs our db server's (cluster) capabilities. The same cannot be told about DRDA. And I couldn't quickly find any clue online that DRDA would support any such role based connection preference. I'm afraid this would already fail at the fact that, with DRDA, you'd first have to reach a server to obtain any information about alternate servers (among which the client then could pick based on role would that be implemented). Alternatively, from what I'm getting from some (Db2 HADR) place is the idea there is to use a virtual IP address which some (HADR manager?) entity then has to (re-)assign to the host hosting the current HADR primary server. BR, Andreas ------------------------------ Andreas Legner Informix Dev HCL Software ------------------------------
OK - thanks very much, everyone. That answers my question: excluding VIP or DNS changes, Connection Manager must be used for DRDA HDR fail-over. I can now proceed with my article knowing that there isn't an easier way. Will post a link here once published. ------------------------------ Doug Lawry Oninit Consulting ------------------------------
Hi Gerd. Could you share your connection string to CM? I'm trying to connect via JDBC (ifxjdbc.jar). Thanks, ------------------------------ Victor Huaquisto Email: victor.huaquisto@gmail.com Lima-Perú ------------------------------
Hello,
Here is my example from a demo environment with all details.
I hope this helps:
SQLHOSTS:
=========
cdr_001 group - - i=1
test1 onsoctcp kalu_demo.ibm.com 9101 g=cdr_001,c=1
test2 onsoctcp kalu_demo.ibm.com 9102 g=cdr_001,c=1
test3 onsoctcp kalu_demo.ibm.com 9103 g=cdr_001,c=1
test4 onsoctcp kalu_demo.ibm.com 9104 g=cdr_001,c=1
test1_dr drsoctcp kalu_demo.ibm.com 9401
test2_dr drsoctcp kalu_demo.ibm.com 9402
cdr_002 group - - i=2
test5 onsoctcp kalu_demo.ibm.com 9105 g=cdr_002
cdr_003 group - - i=3
test6 onsoctcp kalu_demo.ibm.com 9106 g=cdr_003
cm_g group - - i=42
x_prim onsoctcp kalu_demo.ibm.com 9901 g=cm_g
x_read onsoctcp kalu_demo.ibm.com 9902
x_all onsoctcp kalu_demo.ibm.com 9903
dr_prim drsoctcp kalu_demo.ibm.com 9911 g=cm_g
dr_read drsoctcp kalu_demo.ibm.com 9912
dr_all drsoctcp kalu_demo.ibm.com 9913
CONNECTION_MANAGER_CFG:
=======================NAME cm1
LOGFILE ${INFORMIXDIR}/tmp/cm1.log
LOG 1
MSG_DATE 3
SSL_LABEL my_ssl_labelCLUSTER cm1
{
INFORMIXSERVER test1,test2,test3
SLA x_prim DBSERVERS=primary
SLA x_read DBSERVERS=(HDR,RSS)
SLA x_all DBSERVERS=(primary,HDR,RSS)
FOC ORDER=HDR,RSS PRIORITY=1
CMALARMPROGRAM ${INFORMIXDIR}/etc/cmalarmprogram.sh
}
CLUSTER cm_dr
{
INFORMIXSERVER test1_dr,test2_dr
SLA dr_prim DBSERVERS=primary
SLA dr_read DBSERVERS=(HDR,RSS)
SLA dr_all DBSERVERS=(primary,HDR,RSS)
FOC ORDER=DISABLED
}
CONNECTION TEST DRDA:
=====================
[jcc][10521][13706]Command : java com.ibm.db2.jcc.DB2Jcc -url jdbc:ids://kalu_demo.ibm.com:9911/sysmaster -user informix -password ********
[jcc][10516][13709]Test Connection Successful.
DB product version = IFX12100
DB product name = IDS/UNIX64
DB URL = jdbc:ids://xx.xx.xx.xxx:9401/sysmaster
DB Drivername = IBM Data Server Driver for JDBC and SQLJ
DB OS Name = Linux
ONSTAT_G_CMSM
=============
IBM Informix Dynamic Server Version 15.0.1.0AEE -- On-Line (Prim) -- Up 01:00:07 -- 224296 Kbytes
2026-02-09 02:22:11 -- Infrastructure Version: 1Unified Connection Manager: cm1 Hostname: kalu_demo.ibm.com
CLUSTER cm1 LOCAL
Informix Servers: test1,test2,test3
SLA Connections Service/Protocol Rule
x_prim 1 9901/onsoctcp DBSERVERS=primary
x_read 0 9902/onsoctcp DBSERVERS=(HDR,RSS)
x_all 4 9903/onsoctcp DBSERVERS=(primary,HDR,RSS)
Failover Arbitrator: Active Arbitrator, Primary is up
ORDER=HDR,RSS PRIORITY=1 TIMEOUT=1
CLUSTER cm_dr
Informix Servers: test1_dr,test2_dr
SLA Connections Service/Protocol Rule
dr_prim 2 9911/drsoctcp DBSERVERS=primary
dr_read 1 9912/drsoctcp DBSERVERS=(HDR,RSS)
dr_all 0 9913/drsoctcp DBSERVERS=(primary,HDR,RSS)
Failover Arbitrator: Failover is disabled
ORDER=DISABLED
JDBC_CONNECTION_STRING_SQLHOSTS
===============================
jdbc:informix-sqli:/<database>:informixserver=<dbserver>;SQLH_TYPE=FILE;SQLH_FILE=/opt/ifx/etc/sqlhosts
Mit freundlichen Grüßen / Kind regards
Gerd Kaluzinski
Delivery Consultant Data
IBM Technology Expert Labs
Phone: +49 175 228 1983 IBM Deutschland GmbH
Email:
gerd.kaluzinski@de.ibm.com
Mies-van-der-Rohe-Straße 6, 80807 München
IBM Deutschland GmbH
Vorsitzender des Aufsichtsrats: Ivo Körner
Geschäftsführung: Wolfgang Wendt (Vorsitzender), Dr. Andreas Buchelt, Dr. Frank Kohls, Christine Rupp
Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB 14562
I am currently working to get Informix CM (15.0.0.2) to re-direct PAM clients for Primary HDR server (15.0.1.0.3) for the following protocols: onsoctcp, onsocssl, drsoctcp & drsocssl, all using PAM. Currently i have multiple issues: redirect fails after a failover and startup/reconfig time is more than 4 minutes. By any chance can you share what listeners do you have in the CM passwd_file ? ------------------------------ Kenneth Penza ------------------------------
Kenneth: Remember that the DRDA protocol is not the native Informix connectivity protocol, SQLI is. DRDA is the native DB2 protocol and it does not recognize either CM or SQLHOSTS group entries for connection failover. There is no way to fix that as this protocol is owned by the DB2 development group and they have no reason to support Informix's connection failover mechanisms. Unfortunate, but true. ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------