Informix Error -43

Important platform note. Error codes in this range represent operating-system errno values whose meanings vary between Unix platforms and versions. Confirm the native errno definition on the server where the Informix error occurred before diagnosing the problem from the number alone.

Determine the Native Error Meaning

	Value	Symbol
Catalogue text — Protocol not supported	43	EPROTONOSUPPORT on BSD
The same condition on Linux	93	EPROTONOSUPPORT
Errno 43 on Linux	43	EIDRM — Identifier removed

Codes -42 to -55 are the BSD socket block and each sits 50 higher on Linux.

Errno 43 on Linux deserves a moment, because unlike most of the same-number values in this block it is not an obscure STREAMS error. EIDRM means a System V IPC object was removed while in use — shared memory or a semaphore deleted out from under a running process. That is a serious condition for a database server, and it is described on -36, where the System V platforms carry it at errno 36.

So on Linux, confirm which you have before going further: a protocol refusal at 93, or IPC removed at 43.

python3 -c 'import os; print(43, os.strerror(43)); print(93, os.strerror(93))'

Everything below concerns the protocol refusal.

What EPROTONOSUPPORT Actually Tells You

socket() was called with a protocol the address family does not support, or that the kernel does not provide.

It is decided at socket creation, before any address is involved and before anything reaches the network — which makes it a configuration or build problem rather than a runtime one.

The family of refusals, all decided at the same moment and easily confused:

Error	Symbol	What was refused
-43	EPROTONOSUPPORT	The protocol
-44	ESOCKTNOSUPPORT	The socket type
-46	EPFNOSUPPORT	The protocol family
-47	EAFNOSUPPORT	The address family

In practice the four are reported somewhat interchangeably by different stacks for the same underlying mistake, so treat any of them as pointing at the same question: which protocol, family and type were requested, and which does this host provide?

What This Means in Informix

The protocol comes from sqlhosts. Each entry names one — onsoctcp, ontlitcp, onipcshm, onipcstr and their relatives.

The tli / soc case is version-dependent, and both behaviours are awkward

A sqlhosts entry specifying a TLI protocol where the engine uses sockets does not behave consistently across versions, and you need to know which behaviour you have.

Engine version	What happens
Earlier versions	Fail immediately. The protocol is refused and the listener does not start — the error is loud, repeatable and obvious.
Later versions	Fall back quietly. A socket listener is started instead. No error, no message, no indication the configuration was not honoured.

Neither is a safe assumption, and the later behaviour is the more troublesome of the two:

• A failure at least tells you the entry is wrong, on the day you made the change.
• A silent fallback means connections work, the instance is healthy, and sqlhosts describes a configuration that is not the one running. Nobody finds that by waiting for an error, because there will not be one.

So the absence of a -43 does not mean the protocol entry was accepted — on a later version it may mean the engine ignored it. And a -43 on an older version is the same misconfiguration reporting itself properly.

The practical consequence is the same either way: check the running listener rather than trusting the file.

Checking what is actually listening

onstat -g nta is the check. It consolidates the network thread output — ntu, ntt, ntm and ntd — into one view of the running listeners:

onstat -g nta

Compare what that reports against what sqlhosts specifies. A disagreement is the silent fallback, and it is invisible by every other means.

awk '!/^\s*#/ && NF {printf "%-16s %-12s %-20s %s\n", $1, $2, $3, $4}' \
    "${INFORMIXSQLHOSTS:-$INFORMIXDIR/etc/sqlhosts}"
onstat -g nta

On an older version this confirms what the error already told you. On a later one it is the only way to find the mismatch at all, so it is worth doing after any migration or configuration copy as a matter of course rather than in response to a problem.

Where a -43 might genuinely arise

Rarely, and not from the case above:

• A shared-memory or stream-pipe protocol used from a remote client, where only a network protocol can work.
• A protocol requested for an address family that cannot carry it — more often reported as -47, and worth checking together.
• A container or minimal image whose kernel lacks a protocol module the host has.
• Client-side code requesting a protocol the platform does not provide.

Where a later version falls back rather than failing, a -43 that names no obvious cause is worth treating with the suspicion -33 describes — it may be residue rather than evidence. On an older version, the sqlhosts protocol entry remains the first thing to check.

Common Causes

1. A local-only protocol used for a remote connection, or the reverse.
2. A protocol module absent from a minimal or container kernel.
3. A client library built for a different protocol set than the server offers.
4. A protocol requested for an address family that cannot carry it — see -47.

A sqlhosts entry naming the wrong protocol family is deliberately not on that list. That case does not produce an error at all — see above.

Diagnostic Checks

Confirm the symbol first. On Linux this matters more here than anywhere else in the block, because errno 43 is a real and serious condition of its own:

python3 -c 'import os; print(43, os.strerror(43)); print(93, os.strerror(93))'

If it is EIDRM at 43, stop and read -36 — something removed the instance's IPC resources, and that is an incident rather than a configuration question.

Compare sqlhosts against the running listeners. Because the engine can fall back silently, this is the check that matters whether or not an error was reported:

onstat -g nta

Read every protocol entry in use:

cat "${INFORMIXSQLHOSTS:-$INFORMIXDIR/etc/sqlhosts}"
awk '!/^\s*#/ && NF {print $2}' "${INFORMIXSQLHOSTS:-$INFORMIXDIR/etc/sqlhosts}" | sort | uniq -c
grep -nE 'DBSERVERNAME|DBSERVERALIASES|NETTYPE' "$INFORMIXDIR/etc/$ONCONFIG"

The uniq -c line is the quick audit: it shows at a glance whether a file mixes protocol families, which is usually how one wrong entry survives unnoticed.

Check what the host supports:

cat /proc/net/protocols 2>/dev/null | awk '{print $1}' | sort -u | head -20
ss -f inet -l 2>/dev/null | head
ls /proc/net/ 2>/dev/null

Trace the failing call, which names the exact triple that was refused:

strace -f -e trace=socket -p <pid> 2>&1 | grep -iE 'EPROTONOSUPPORT|EAFNOSUPPORT|EPFNOSUPPORT'

# Solaris / AIX
truss -f -t so_socket,socket -p <pid>

And the engine's record:

tail -300 "$INFORMIXDIR/tmp/online.log"
onstat -g ntt

Solutions / Resolution

1. Confirm the symbol before anything else. On Linux, errno 43 at its own number is EIDRM and means something quite different and much more serious — see -36.
2. Compare onstat -g nta against sqlhosts regardless of whether an error was reported. The behaviour is version-dependent: earlier versions refuse the protocol outright, later ones start a socket listener and say nothing. The absence of an error is therefore not confirmation that the entry was honoured.
3. Audit every protocol entry in sqlhosts, not just the failing one. A file carried between platforms usually has more than one entry that needs revisiting.
4. Match the protocol to the platform. Use the network protocol the current platform and version document, rather than the one that worked on the previous system.
5. Use a local protocol only for local connections. A shared-memory or stream-pipe entry cannot serve a remote client, and the resulting failure is a configuration error rather than a network one.
6. Review the protocol field during any migration as a matter of course, alongside device paths (-15) and SERVERNUM (-17). These are the fields that do not travel.
7. In a container, check the container's kernel view, not the host's.

Example

The entry says TLI; the listener is a socket

$ awk '!/^\s*#/ && NF {print $1, $2}' "${INFORMIXSQLHOSTS:-$INFORMIXDIR/etc/sqlhosts}"
ol_prod ontlitcp

$ onstat -g nta

The listener reported by the engine is a socket listener. The configuration was carried from a System V platform, the TLI entry was never revised, and the engine started what it could rather than refusing.

On a later version nothing is broken and nothing will report it. Connections work, applications work, and the file describes a configuration that is not the one running. It surfaces much later — when someone tunes a parameter that applies only to the protocol they believe is in use, or when the entry is copied onward to another host.

On an earlier version the same entry would have refused to start the listener and the fault would have been found immediately. The upgrade that made the engine more forgiving is what allows this to persist unnoticed.

The comparison above is the only way to find it, and it takes two commands.

Platform Note

Platform	This condition	Errno 43 there means
Linux	errno 93	EIDRM — IPC removed while in use; see -36
Solaris, AIX, HP-UX	confirm on the host	confirm on the host
BSD, Darwin	errno 43	this condition

This is the one code in the block where the same-number Linux value is itself significant, so the usual advice to confirm the symbol carries real weight rather than being a formality.

Protocol naming is the least portable part of an Informix network configuration. The TLI-based entries belong to the System V lineage and the socket-based ones are the Linux convention; a sqlhosts file is therefore platform-specific in a way that is easy to overlook when copying one.

Related Errors / Related Topics

• -36 — on the System V platforms, EIDRM. On Linux that condition sits at errno 43, the same number as this code. Read it if the symbol check returns EIDRM.
• -46 — Protocol family not supported, and -47 — Address family not supported. The neighbouring refusals, decided at the same moment and frequently reported in place of one another.
• -44 — Socket type not supported, the fourth member of the same family.

Where a protocol is refused, the failure is immediate and repeatable. That alone separates it from anything on the network, and makes the sqlhosts audit the first and usually the only step.