Informix Error -152
-152 ISAM error: Illegal message type received from remote process.
This internal error should not occur. Note all the details about the network software in use and the version level of the database servers in this and the other host system. If the error recurs, note all circumstances and contact IBM Informix Technical Support.
Oninit® Troubleshooting Guidance
Reasons / Common Causes
-152 is a distributed/networked communication error — one database process received a message from a remote process that it doesn't recognize as valid. The official text is direct that this "should not occur," and frames the investigation specifically around version and network-software compatibility between the two hosts involved, rather than application-level troubleshooting.
- A version mismatch between database servers on different hosts — in a distributed or Informix STAR-style deployment, one host running a different server version whose inter-node message protocol doesn't match what the other expects.
- Network software (connectivity drivers, middleware) version incompatibility between the two systems, independent of the database server version itself.
- A partial or incomplete upgrade across a distributed deployment — one node upgraded, others left on the previous version, breaking the expected inter-node message protocol during the transition period.
- Mixed connectivity/driver patch levels across different hosts in the same distributed deployment.
- Network-path corruption or interference altering message bytes in transit — less common than a version mismatch, but possible with an unreliable network path or misconfigured middleware sitting between the hosts.
Solutions / Resolution
- Note all details about the network software in use and the version level of the database servers on both this host and the other host system, per the official guidance — this is fundamentally a version/compatibility investigation, not something to diagnose from application code.
- Verify all nodes in a distributed deployment run compatible, matched versions of both the database server and the networking/connectivity software.
- If a recent upgrade was performed on only some nodes, complete it consistently across all nodes rather than leaving a mixed-version deployment in place, even temporarily.
- If corruption in transit is suspected rather than a straightforward version mismatch, investigate the network path itself — switches, routers, firewalls, or any packet inspection/modification middleware between the hosts.
- If none of the above explains a recurrence, document exact circumstances — versions on both sides, network software details, timing — and escalate to IBM Informix Technical Support, per the official guidance's own framing of this as something that shouldn't happen.
Examples
The mixed-version rollout
Host A: database server version X.X.X (upgraded)
Host B: database server version X.X.(X-1) (not yet upgraded)
A distributed deployment mid-rollout, with nodes on different versions, is exactly the kind of state where inter-node message protocols can diverge — completing the rollout consistently resolves this, not investigating the specific message that failed.
Gathering the right diagnostic detail
-- Before contacting support, confirm and record:
-- 1. Database server version on this host
-- 2. Database server version on the remote host
-- 3. Network/connectivity software version on both
-- 4. Whether a recent upgrade or network change coincides with onset
Diagnostic Checks
- Compare database server versions on both hosts involved in the failing communication.
- Compare network/connectivity software versions on both hosts.
- Review recent upgrade history for a partial or incomplete rollout across distributed nodes.
- Check network path health — switches, routers, firewalls, middleware — if version mismatch has been ruled out.
Related Errors / Related Topics
- -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
- -140 — "ISAM error: operation illegal on a DR secondary." The other error in this range specific to distributed/multi-host Informix deployments — worth reviewing together if troubleshooting a distributed environment more broadly.
Confirm version alignment across every host in the deployment before anything else — this is by far the most common actual explanation for a message one side doesn't recognize from the other.