Oninit
Talk to an expert →

Informix Error -42

-42 Option not supported by protocol.

An operating-system error code with the meaning shown was unexpectedly returned to the database server. If the error recurs, note all circumstances and contact IBM Informix Technical Support.

Oninit® Troubleshooting Guidance

This is an operating-system error number, not an Informix diagnosis.

The same errno is returned by many different operations, so on its own it says what the operating system refused, not what Informix was trying to do. Informix will usually have reported a more specific error alongside it — in the message log, in the SQL or ISAM error pair, or in the accompanying assert failure — and that error normally defines the real cause far more precisely than the errno does. Find it before diagnosing from this number alone.

This matters less than it used to. Later versions of the engine trap many of these conditions and report them as specific Informix errors naming the operation, the object and the context, so a bare errno in this range is increasingly a sign of an older version, an unusual code path, or a failure early in startup before the better reporting is available. If you are seeing one on a current version, the more specific error is worth looking for even harder.

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 — Option not supported by protocol 42 ENOPROTOOPT on BSD
The same condition on Linux 92 ENOPROTOOPT
Errno 42 on Linux 42 ENOMSG — No message of desired type, System V message queues

-42 is the first of the BSD socket block (-42 to -55), every member of which sits 50 higher on Linux.

python3 -c 'import os; print(42, os.strerror(42)); print(92, os.strerror(92))'
What ENOPROTOOPT Actually Tells You

setsockopt() or getsockopt() named an option the protocol does not implement. The socket is fine, the operation is fine, and the specific option is not available at the level it was requested for.

The commonest form is an option requested at the wrong level — a TCP option passed with SOL_SOCKET, or a socket option passed with IPPROTO_TCP. The name is right and the level is wrong, and the kernel reports the option as unsupported because at that level it genuinely is.

The distinction from its neighbours:

Error Symbol What was refused
-42 ENOPROTOOPT The option — this protocol has no such option
-43 EPROTONOSUPPORT The protocol
-45 EOPNOTSUPP The operation, on this kind of socket
-22 EINVAL The argument — right option, unacceptable value

EINVAL is the one to keep separate. An option that exists but was given a value out of range produces -22, not this.

What This Means in Informix

This is not an error the engine produces in normal operation, and it is rare enough that a -42 usually points at something adjacent rather than at the database:

  • Socket tuning applied per connection — keepalive intervals, TCP_NODELAY, buffer sizes — where an option available on one platform is not available on another. This is the realistic case, and it appears after a migration rather than spontaneously.
  • A connection-handling library or driver built against different headers from the platform it runs on.
  • A C UDR or external routine opening its own socket and setting options without checking the platform.
  • A protocol mismatch in sqlhosts where an option makes sense for one protocol entry and not another.
  • A container or sandbox where an option is filtered rather than unimplemented — in which case the error may be EPERM (-1) or ENOSYS (-38) instead, depending on how the filter is configured.

A configuration that worked on one platform and fails on another is the shape to expect, because socket options are among the least portable things in a network stack.

Common Causes
  1. A socket option unavailable on this platform, applied by tuning carried across from another.
  2. An option requested at the wrong level — SOL_SOCKET against IPPROTO_TCP or the reverse.
  3. A client library or driver compiled against newer or different headers.
  4. Custom code in a UDR or wrapper setting options without a platform check.
  5. A sandbox filtering the call, where the failure may present as a different errno entirely.
Diagnostic Checks

Confirm the symbol, since errno 42 on Linux is a message-queue error and unrelated:

python3 -c 'import os; print(42, os.strerror(42)); print(92, os.strerror(92))'

Find the call. Nothing else identifies which option was refused, and the option name is the whole answer:

strace -f -e trace=setsockopt,getsockopt -p <pid> 2>&1 | grep -iE 'ENOPROTOOPT|EINVAL'

# Solaris / AIX
truss -f -t setsockopt,getsockopt -p <pid>

The traced line names both the level and the option, which is exactly the pair that is usually mismatched.

Check what the platform supports:

man 7 socket | grep -A2 -iE 'SO_KEEPALIVE|SO_RCVBUF|SO_SNDBUF' | head -20
man 7 tcp    | grep -iE 'TCP_KEEPIDLE|TCP_NODELAY|TCP_USER_TIMEOUT' | head

Check the connection configuration for options applied per connection:

cat "${INFORMIXSQLHOSTS:-$INFORMIXDIR/etc/sqlhosts}"
grep -nE 'NETTYPE|DBSERVERALIASES' "$INFORMIXDIR/etc/$ONCONFIG"

And the engine's own record:

tail -300 "$INFORMIXDIR/tmp/online.log"
onstat -g ntt
onstat -g ntu
Solutions / Resolution
  1. Identify the option by tracing. Every remedy depends on knowing which option and which level, and nothing else will tell you.
  2. Check the level before the option name. A correct option at the wrong level is the most common cause and looks identical to an unsupported one.
  3. Treat it as a portability question after a migration. Socket options are among the least portable parts of a network stack; a tuning script that ran for years on one platform is not evidence that it will run on another.
  4. Do not remove the option blindly. Establish what it was doing — a keepalive interval or a buffer size may have been solving a real problem, and dropping it silently reintroduces that problem later.
  5. For custom code, guard the call. Setting an option and ignoring the result is preferable to failing outright where the option is an optimisation rather than a requirement, but the decision should be explicit.
  6. If the environment is a container, check whether the call is being filtered rather than unimplemented — see -38, where the same question arises about system calls.
Example
The option is right, the level is not
$ strace -f -e trace=setsockopt -p 4412 2>&1 | grep -i noproto
setsockopt(9, SOL_SOCKET, 0x4 /* TCP_??? */, [600], 4) = -1 ENOPROTOOPT (Protocol not available)

A TCP-level option requested at SOL_SOCKET. The option exists; at that level it does not. The traced line shows both halves, and the fix is in the code that made the call rather than anywhere in the database configuration.

Platform Note
Platform This condition Errno 42 there means
Linux errno 92 ENOMSG — System V message queues, unrelated
Solaris, AIX, HP-UX confirm on the host confirm on the host
BSD, Darwin errno 42 this condition

Socket option availability is itself the least portable thing here. TCP_KEEPIDLE, TCP_USER_TIMEOUT and their relatives differ in name, availability and units between Linux, Solaris and AIX, and the per-platform documentation is the only reliable source.

Task Linux Solaris AIX
Trace the call strace -e setsockopt truss -t setsockopt truss -t setsockopt
Option reference man 7 socket, man 7 tcp man -s3socket setsockopt man setsockopt
Stack tunables sysctl net.ipv4.* ipadm show-prop tcp no -a
Related Errors / Related Topics
  • -43 — Protocol not supported. The protocol itself rather than one of its options.
  • -45 — Operation not supported on socket, where the operation is wrong for this kind of socket rather than the option being absent.
  • -22 — Invalid argument. The option exists and the value was not acceptable. Easy to confuse with this, and much more common.

A -42 is a code or portability question rather than an operational one. Trace the call, read the level and the option together, and the answer is usually in the line itself.