Informix Error -153: ISAM error: not in ISMANULOCK mode.

Reasons / Common Causes

-153 is a C-ISAM mode mismatch: islock()/isunlock() (manual lock/unlock calls) were used against a file that wasn't opened with the ISMANULOCK flag. Without that flag, the file uses automatic locking — the ISAM library manages locks implicitly around each operation — and explicit manual lock/unlock calls simply aren't meaningful against it.

1. The file was opened without ISMANULOCK, but code elsewhere calls islock()/isunlock() against it directly — the straightforward mismatch the official text describes.
2. Code copied or ported from a program that does use manual locking, into a context where the corresponding isopen() call was never updated to include ISMANULOCK — a copy-paste gap between the open call and the code that assumes manual lock control is available.
3. A refactor that changed a file's isopen() flags (removing ISMANULOCK for some reason) without updating downstream code that still calls manual lock/unlock functions against it.
4. Confusion between automatic and manual locking modes — a developer assuming explicit lock control is available by default, without realizing it requires opening the file in a specific, different mode.
5. Shared or library code assuming ISMANULOCK was set by the caller, when in some call paths it wasn't.

Solutions / Resolution

1. Add the ISMANULOCK flag to the isopen() call for any file where manual lock/unlock functions will be used — review the calls per the official guidance.
2. If manual locking isn't actually needed, remove the explicit islock()/isunlock() calls and let automatic locking (the default) manage this instead — simpler, and avoids the mismatch entirely when manual control isn't genuinely required.
3. For shared or library code, make lock-mode expectations explicit — document or assert the requirement rather than assuming every caller opens files in the mode the library code expects.
4. Review any refactor that changed a file's isopen() flags to confirm all downstream manual-lock-dependent code was updated in step with it.

Examples

The straightforward mismatch

int fd = isopen("orders", ISINPUT);   /* no ISMANULOCK */
islock(fd);                            /* -153: file isn't in manual lock mode */

Fix, if manual locking is genuinely needed:

int fd = isopen("orders", ISINPUT | ISMANULOCK);
islock(fd);                            /* now valid */

Or, if manual locking isn't actually needed:

int fd = isopen("orders", ISINPUT);   /* automatic locking handles this */
/* no explicit islock()/isunlock() calls needed */

A refactor that dropped the flag

/* Before: */
int fd = isopen("orders", ISINPUT | ISMANULOCK);

/* After an unrelated refactor simplifying open flags: */
int fd = isopen("orders", ISINPUT);   /* ISMANULOCK silently dropped */

/* Existing code elsewhere still calls islock()/isunlock() against fd,
   now failing with -153 */

The fix is restoring ISMANULOCK (or removing the now-orphaned manual lock calls), not changing the lock calls' logic itself.

Diagnostic Checks

1. Review the isopen() call for the failing file — confirm whether ISMANULOCK is present.
2. Review whether the calling code genuinely needs manual lock control, or was written assuming a mode the file wasn't actually opened in.
3. Check for a recent change to the isopen() flags for this specific file, if the mismatch appeared without an obvious cause in the calling code itself.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -107 — "ISAM error: record is locked." Part of the broader locking family this error belongs to, though -153 is specifically about mode mismatch rather than an actual lock conflict.

Check the file's isopen() flags first — this is a configuration mismatch between how the file was opened and how it's being used, not a locking conflict with another session.