Informix Error -121

Reasons / Common Causes

-121 is a write-time failure against the transaction log — the ISAM processor tried to add a new record and the OS refused. The official text names disk space directly as the likely cause, and also gives the standing maintenance practice that prevents it from recurring.

1. The filesystem hosting the log is full. This is the officially named, most direct cause — the transaction log can grow quite large over time, and if nothing ever reclaims that space, it eventually consumes everything available.
2. The log file has grown large without routine truncation. The official maintenance procedure (back up the data, then empty the log file) exists specifically to keep this from happening — if it isn't performed routinely, growth is effectively unbounded.
3. An undersized filesystem or partition allocated for the log relative to the actual write volume the workload produces.
4. A filesystem quota exceeded, distinct from raw space exhaustion — the same class of cause as -115.
5. The log sharing a filesystem with unrelated data that's growing independently, indirectly starving the log's own room to grow even though the log itself isn't unusually large.

Solutions / Resolution

1. Check disk space on the log's filesystem immediately — this is the first thing to rule out given how directly the official text points at it.

2. Follow the official two-step maintenance routine, done routinely rather than reactively:

   • First, make a backup copy of the data file (C-ISAM) or all database files (SQL).
   • Second, empty the transaction-log file.

   Performed on a schedule, this keeps the log's size under control before it ever approaches filling its filesystem.

3. Increase the size of the filesystem/partition hosting the log if it's genuinely undersized for the actual write volume — a one-time maintenance routine only goes so far if the underlying allocation is simply too small.

4. Move the log onto its own dedicated filesystem if it currently shares space with unrelated, independently-growing data — this both prevents indirect starvation and makes log growth easier to monitor in isolation.

5. Establish a scheduled backup-and-truncate job rather than relying on someone remembering to run it manually — the official guidance's own phrasing ("if you perform these steps routinely") implies this is meant to be a standing practice, not an occasional cleanup.

6. Check for other, unrelated consumers of the same filesystem if space is disappearing faster than the log's own growth would explain, and relocate them if found.

7. Check filesystem quotas separately from raw usage if space appears available but writes still fail.

Examples

The routine maintenance procedure

# 1. Back up the data first
ontape -s -L 0            # or the equivalent backup procedure for the product in use

# 2. Then empty the transaction-log file
# (specific mechanism depends on product/version — the key sequencing
#  point is: backup completes and is verified BEFORE the log is emptied)

Doing this on a schedule — weekly, or whatever cadence matches the actual write volume — is what the official guidance means by "if you perform these steps routinely, you can control the size of the log file." Skipping it is what leads to -121 eventually, not any single large operation.

Diagnosing a sudden disk-full condition

$ df -h /informix/logs
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc1        20G   20G     0 100% /informix/logs

If the log's filesystem shows 100% used, -121 is the expected consequence, not a mystery to investigate further — the fix is space (immediate) and a maintenance routine (durable), not a code change.

Diagnostic Checks

1. Check disk space on the log's filesystem:

   df -h /informix/logs
   

2. Check the log file's size trend over time — a steadily growing log with no corresponding truncation events is the signature of a missing maintenance routine, not a one-time spike.
3. Check maintenance job history for whether the backup-and-truncate routine has actually been running, and on what schedule.
4. Check for other large or unexpected files on the same filesystem if the log itself doesn't account for the space being consumed.
5. Check filesystem quotas if space appears available at the block level but writes still fail.

Related Errors / Related Topics

• -115 — "ISAM error: cannot create lock file." The same class of OS-level resource exhaustion (disk space, permissions) applied to a different file.
• -120 — "ISAM error: cannot open log file." A different failure against the same general resource — -121 fails while writing to a log file that's already open; -120 fails at open time.

If -121 recurs after a single space cleanup, the real fix is establishing the routine backup-and-truncate maintenance the official text describes — a one-time space increase without that routine just delays the next occurrence.