«

On 12/17/2012 12:53 PM, jk__c wrote:
> Hi,
>
> I have compiled a C program in Tandem server. (This program was successfully compiled and tested in windows environment.) However while trying to run the object file generated in Tandem (ofcourse in a Tandem server), I get the below error
> UNDEFINED DATA BLOCK MAP BY NAME FOR FILE: <object file name>
>
> NAME
>
> $_ctype
> _ctype_local
>
> Can some one let me know the remedy for this please?
> JK

Possibly - but if so, they may need more information. Is that the full
exact text of the error message? Even the "object file name" part? If
not, please provide the full error message. The options you passed to
the compiler would also be helpful. The single most helpful thing you
could provide, however, would be a version of the code that fails to
compile, which has been trimmed to be as small as possible while still
demonstrating that failure. Make sure, before posting, that the
simplified version you're posting does indeed still fail to compile.

On Mon, 17 Dec 2012 13:20:48 -0500, James Kuyper
<> wrote:

> On 12/17/2012 12:53 PM, jk__c wrote:

[manually "fixed" unreadably long quoted line, please don't do that]

> > I have compiled a C program in Tandem server. (This program
was successfully compiled and tested in windows environment.) However
while trying to run the object file generated in Tandem (ofcourse in a
Tandem server), I get the below error
> > UNDEFINED DATA BLOCK MAP BY NAME FOR FILE: <object file name>
> >
> > NAME
> >
> > $_ctype
> > _ctype_local
> >
> > Can some one let me know the remedy for this please?
> > JK
>
I don't believe an error like that would occur at run time; it should
occur at link time or more exactly "bind" time, see below.

> Possibly - but if so, they may need more information. Is that the full
> exact text of the error message? Even the "object file name" part? If
> not, please provide the full error message. The options you passed to
> the compiler would also be helpful. The single most helpful thing you
> could provide, however, would be a version of the code that fails to
> compile, which has been trimmed to be as small as possible while still
> demonstrating that failure. Make sure, before posting, that the
> simplified version you're posting does indeed still fail to compile.

1. "Tandem" systems are fairly rare. There is a newsgroup specifically
for them comp.sys.tandem which contains a greater concentration of
knowledge than I think comp.lang.c does.

2. There were two majorly different architectures brought out by
Tandem while it was a separate company, and a third superceding one
after it was acquired by Compaq (and after I stopped working on them).
All of them support the original/traditional Tandem NonStop ISA, aka
"TNS" or "CISC" mode. The second and third also have (different)
"native" modes called TNS/R and TNS/E. Programming for these modes
differs significantly, especially in C which is somewhat closer to the
machine than other HLLs, so you need to specify. And within TNS mode
there were three different memory models, which are compiled and
linked (called "bound") slightly differently; I don't believe there
are similar models for native but that is mostly after my experience.

$_ctype looks to me like a symbol that might belong in the runtime
library for one TNS model, and thus an error on it might be because
you are using a wrong memory model or trying to mix them.

On 12/23/2012 06:14 AM, David Thompson wrote:
....
> 1. "Tandem" systems are fairly rare. There is a newsgroup specifically
> for them comp.sys.tandem which contains a greater concentration of
> knowledge than I think comp.lang.c does.

True - but it's entirely possible that the problem with his code is a C
defect that happens to cause no problems on the Windows system where it
worked, but does cause a problem on a Tandem system. That would make it
a C problem, not a Tandem problem. I didn't want to tell him to go
somewhere else until I had enough information to rule out that possibility.
--
James Kuyper