Yes, it is serious, although I must confess I have trouble taking
it seriously myself.

The workaround lies with unlinking a hard-linked file and using a
copy of it instead.  The cause seems to be the excessive number of
hard links (either side of a hundred when we hit problems) and I
am assuming that SCO emulation contributes to the problem, although
this is totally speculative.

The symptoms are quite weird, too, as we get the RM-Cobol runtime
reporting that the file it opened is the wrong format, when in fact
it opened a file by entirely the wrong name.  How it establishes
such a name is a mystery: up until the OPEN instruction, the actual
textual string is exactly as required.

In summary, we have a utility that is executed a large number of
times for various configurations, and occasionally hiccups when
hitting one of many multiply-linked files, by seemingly being
sidetracked to a totally different file (in the same directory).

I'm hoping that the symptoms ring a bell somewhere, because trying
to identify the source of the problem is not going to be trivial
(I did forget that we can do kernel tracing), and I'm a little
remote from the place where the error occurs.

I haven't established the critical number of hard links involved.
It would be a long procedure, but because the error is repeatable,
it can be done.

This is all occurring under:
NetBSD grin 1.4 NetBSD 1.4 (GRIN) #0: Fri Aug 20 03:41:32 PDT 1999     root@grin:/usr/src/sys/arch/i386/compile/GRIN i386
with various emulations enabled.

Suggestions as to where I should start searching?  I have a suspicion
that symbolic links will work better, and I can test this in the
next couple of days - but I'd like to get to the bottom of the
problem, it seems like one of those unpredictabilities that should
be stomped out.  Naturally, the problem does not manifest itself in
any fashion on the SCO Open Server that is used for similar operations.

++L