Informix Error -120

Reasons / Common Causes

-120 is an OS-level open failure against the transaction log file specifically — similar in spirit to -115's lock-file creation failure, but for the log file, and reached at open time rather than during a read. The official text splits the two realistic origins cleanly:

For C-ISAM programs:

1. The wrong filename or path was passed to islogopen() — a typo, a relative path that doesn't resolve the way the code assumes, or a path missing entirely when the log file isn't in the process's current working directory.
2. The file named doesn't actually exist, or isn't writable, at the location the program expects.

For SQL products:

3. The log file was moved, renamed, or deleted after START DATABASE established its location. Whatever directory the log file lived in when the database was started is where subsequent opens look for it — if it's not there anymore, this fails.
4. Permissions changed on the log file or its directory since it was established, so the account attempting to open it no longer has write access.
5. The filesystem or mount hosting the log file became unavailable — unmounted, a dropped network share, or removed storage.
6. Disk space exhaustion preventing the file from being opened for write if opening implies extending it.
7. A restore or rebuild that didn't recreate the log file itself alongside the data — the database's data might be back, but the log file's original location and content weren't part of what was restored.

Solutions / Resolution

For C-ISAM programs:

1. Verify the exact filename parameter passed to islogopen() — confirm it names an existing, writable file, and use an absolute path rather than relying on the process's current working directory being what the code assumes.

For SQL products:

2. Confirm the log file still exists in the same directory location as when START DATABASE was issued — if it was moved, either restore it to that location or reissue START DATABASE pointing at the correct current location, if your version supports that.
3. Fix permissions so the relevant account has write access to both the log file and its containing directory.
4. Confirm the filesystem/mount hosting the log file is actually available — not unmounted, not a dropped network share.
5. Check disk space if the open needs to extend or create the file.
6. After any restore or rebuild, confirm the log file itself was properly recreated or restored alongside the rest of the database — don't assume it's automatically part of a data restore.
7. Read the accompanying OS error message — per the official guidance, this is the fastest path to the specific cause (a missing file, a permissions denial, or an unavailable mount each produce a distinct, identifiable OS error).

Examples

The relative-path bug in C-ISAM

/* Assumes the process's working directory always contains translog.dat —
   true when launched one way, false when launched another */
islogopen("translog.dat");
/* -120 if the process's actual working directory doesn't contain it */

/* More robust: */
islogopen("/informix/logs/translog.dat");

The log file moved after START DATABASE

START DATABASE mydb;
-- log file established at /informix/logs/mydb.log

-- Sometime later, an operator moves the logs directory during
-- unrelated maintenance, without updating the database's expectation

-- Subsequent operation needing the log:
-- -120: /informix/logs/mydb.log no longer exists at the expected location

The fix is restoring the file to its original location (or reissuing START DATABASE correctly if the version supports relocating it), not searching for a workaround at the application level.

Permissions changed underneath

$ ls -la /informix/logs/mydb.log
-rw------- 1 root informix 1048576 Sep 20 03:00 /informix/logs/mydb.log
# should be writable by the informix service account, not root-only

A permissions change made for an unrelated reason (a security audit, a backup tool running as a different user) can silently break subsequent log access.

Diagnostic Checks

1. Verify the exact path being used — the islogopen() argument for C-ISAM, or the directory location active when START DATABASE was originally issued for SQL.
2. Confirm the file's existence and permissions directly:

   ls -la /informix/logs/mydb.log
   

3. Check the mount status of the filesystem hosting the log file:

   mount | grep informix
   

4. Read the specific OS error accompanying -120 — it typically identifies the exact syscall failure (missing file, permission denied, unavailable mount) directly.
5. Check disk space on the filesystem hosting the log if the open needs to extend or create the file.

Related Errors / Related Topics

• -115 — "ISAM error: cannot create lock file." The closest sibling in cause — both are OS-level failures to access a file the ISAM processor needs (a lock file there, the transaction log here), and the same diagnostic approach (check the OS error, permissions, disk space, mount status) applies to both.
• -118 — "ISAM error: cannot read log record." A different failure against the same general resource — -120 is failing to open the log file at all; -118 is failing to read a specific record from a log file that did open successfully.

Read the OS-level error message accompanying -120 before investigating further — it almost always names the specific problem (missing file, permission denied, unavailable filesystem) directly, turning this into a quick fix rather than an extended investigation.