Informix Error -63

-63 File name too long.

An operating-system error code with the meaning shown was unexpectedly returned to the database server. An error might exist in the coding of a REPORT TO statement of a report. If not, 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 — File name too long	63	`ENAMETOOLONG` on BSD
The same condition on Linux	36	`ENAMETOOLONG`
Errno 63 on Linux	63	`ENOSR` — Out of streams resources; see -74

Another code whose condition Linux reports at a much lower number.

python3 -c 'import os; print(36, os.strerror(36)); print(63, os.strerror(63))'

On Linux, ENAMETOOLONG is errno 36, so the engine reports it as -36. The full treatment is there:

Error -36 — the PATH_MAX against NAME_MAX distinction, why symlink resolution lengthens a path, byte limits against character counts, and the checks that find an over-long component.

The Condition, in Short

A pathname, or a single component of one, exceeded what the filesystem or the kernel will accept.

Two separate limits apply and confusing them is the usual reason these take longer than they should:

Limit	Typical Linux value	Applies to
`PATH_MAX`	4096	The whole pathname
`NAME_MAX`	255	One component between slashes

The component limit is the one usually breached. A generated filename that concatenates instance, dbspace, timestamp and sequence number can pass 255 bytes while the full path is nowhere near 4096 — so measuring the path and concluding it is fine is a wrong answer arrived at honestly.

basename "$P" | wc -c          # check this one
printf '%s' "$P" | wc -c       # not just this one
getconf NAME_MAX /path

Two further traps, both covered on -36: symlink expansion lengthens the resolved path, and the limit belongs to the filesystem rather than the host — an NFS export may accept less than the local one.

Side note. Informix applies its own maximum length to a chunk path, separate from these limits and shorter than both — and shorter again on a non-root installation. The engine refuses rather than the kernel, so the checks here will show nothing wrong with the path. Check the figure for your version before laying out a storage tree.

About the Official Text

The catalogue points at REPORT TO in a 4GL report, which is a plausible source: a report writing to a generated output filename is exactly the kind of path assembled from several fields without anyone counting.

It is not the only one, and on a modern installation it is not the likeliest. Backup and archive targets with generated names are the common case, along with DUMPDIR and assert-failure filenames, external-table data files named from job metadata, and any tree relocated below an already-long mount point by a restore or a container image. Those are listed on -36.

Diagnostic Checks

Confirm the symbol, which decides which page applies:

python3 -c 'import os; print(63, os.strerror(63))'

Result	Meaning	Read
`File name too long`	`ENAMETOOLONG` — BSD or System V	this condition, detail on -36
`Out of streams resources`	`ENOSR` — Linux errno 63	-74, a different condition

If it is ENAMETOOLONG, measure the component rather than the path:

basename "$P" | wc -c
readlink -f "$P" | wc -c
getconf NAME_MAX "$(dirname "$P")"
getconf PATH_MAX "$(dirname "$P")"

Find offenders across a tree in one pass:

find /informix -xdev -printf '%f\n' 2>/dev/null | awk 'length($0) > 200 {print length($0), $0}' | sort -rn | head

On a Linux host, expect this condition at -36 rather than here.

Solutions / Resolution

Confirm the symbol first. On Linux, errno 63 is ENOSR and this code is not what you have.
For ENAMETOOLONG, go to -36. The measurement method, the NFS case and the symlink interaction are all there.
Measure the component, not just the path. Most of these are a 255-byte filename inside a perfectly reasonable directory.
Shorten the generated name rather than the directory structure. A scheme encoding four fields and a timestamp usually has one field that adds nothing — a hostname implied by the directory it is written to, for instance.
Check getconf against the target filesystem, especially where a backup writes to NFS. The limit is the filesystem's, not the host's.

Platform Note

Platform	`ENAMETOOLONG` is	Errno 63 there means
Linux	errno 36 — reported as -36	`ENOSR`, Out of streams resources — see -74
Solaris, AIX, HP-UX	confirm on the host	confirm on the host
BSD, Darwin	errno 63	this condition

As with -62, the catalogue carries one condition at two codes: this entry from the BSD numbering, and -36 from the value Linux uses. A Linux instance reports -36.

The limits themselves are not portable either. NAME_MAX is 255 on most modern filesystems but PATH_MAX and the filesystem-specific values differ, and getconf against the specific path is the only reliable answer on any platform.

Related Errors / Related Topics

-36 — where this condition is reported on Linux, and where the full treatment lives.
-2 — No such file or directory. A truncated or malformed path usually produces that rather than this, and the two are worth checking together when a generated path is involved.
-74 — what errno 63 means on Linux.

Where -63 appears, confirm the symbol and then read -36. On a Linux host this condition does not carry this number.