Oninit
Talk to an expert →

Informix Error -73

Cause and resolution

Timer expired.

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 — Timer expired 73 ETIME — STREAMS-era
The same symbol on modern Linux 62 ETIME — Timer expired (exact text match)
Errno 73 on Linux 73 EDOTDOT — RFS specific error, unrelated 
python3 -c 'import errno, os; print(62, os.strerror(62)); print(73, os.strerror(73))'

The catalogue text matches modern Linux's ETIME message word-for-word, which is a strong signal the symbol identification itself is right — but the number Informix's catalogue uses (73) is still not modern Linux's number (62) for that same symbol. The exact originating platform/era for the number 73 specifically isn't independently confirmed here; treat it the same as -70/-71's established pattern and verify against the actual reporting host.

What ETIME Actually Tells You

ETIME is a STREAMS-era timeout condition: a STREAMS ioctl (or an operation with a similar bounded-wait contract) was issued with a timer, and that timer elapsed before the operation completed or a response arrived. Unlike a generic "the whole request failed" error, ETIME specifically means the mechanism was working, it just didn't finish inside the allotted window — the underlying stream, device, or peer may still be functional.

What This Means in Informix

Per the official text, this is an OS-level error code reaching the database server unexpectedly. Historically, on STREAMS-based platforms this could surface around:

  • STREAMS-based terminal or pseudo-terminal I/O with a bounded-wait ioctl, if the peer (or the underlying device) was slow enough to exceed the timer.
  • STREAMS-based network transport modules, on platforms that implemented connectivity through STREAMS, for an operation with its own internal timeout distinct from any application-level or TCP-level timeout Informix itself might separately report.
  • Any driver-level operation that uses a STREAMS timed ioctl internally, regardless of what higher-level Informix operation triggered it.

On modern non-STREAMS platforms this specific mechanism generally isn't in play, so seeing this error on a current install is worth treating as a signal to check exactly what operation and device were involved before assuming it means the same thing it meant on the STREAMS-era platform the catalogue text describes.

Common Causes
  1. A STREAMS-level bounded-wait operation genuinely timing out — the direct, named cause.
  2. A slow or overloaded peer/device that doesn't respond inside the timer window, without the underlying connection or device itself having failed.
  3. A timer value set too aggressively for the actual latency of the device or link involved, on platforms/configurations where that timer is tunable.
Solutions / Resolution
  1. Identify exactly which operation and device were involved, from the accompanying error context in the online log — the official text names no further specifics on its own.
  2. Check whether the underlying device or peer is generally healthy, since ETIME implies a timeout rather than an outright failure — retry once conditions are confirmed normal.
  3. If the timeout is tunable on the platform involved, consider whether the timer window is appropriate for the observed latency of the device or link.
  4. If the error recurs and the cause isn't evident, note all circumstances and contact IBM Informix Technical Support, per the official guidance.
Examples
N/A

No specific triggering statement is documented beyond an operating-system error code unexpectedly returned to the database server — the official text gives no further detail.

Diagnostic Checks
  1. Confirm the symbol and its native value on the reporting host:
    python3 -c 'import errno, os; print(62, os.strerror(62)); print(73, os.strerror(73))'
  2. Check what operation/device was involved, via the accompanying online log entries around the same timestamp.
  3. Confirm the underlying device or peer isn't otherwise failing, distinguishing a genuine timeout from a masked hard failure.
Related Errors / Related Topics
  • -70 — Stale NFS file handle. Same operating-system-errno cluster, same platform-dependent-numbering caveat.
  • -71 — Too many levels of remote in path. Same cluster, same caveat.
  • -72 — Not a stream device. Adjacent STREAMS-era symbol — -72 is "no STREAMS capability at all," -73 is "had the capability, timed out waiting on it."

A STREAMS-level operation timing out rather than failing outright — confirm the device or peer involved is otherwise healthy before assuming a harder failure underlies it.