Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!rutgers!sri-spam!mordor!lll-tis!ptsfa!hoptoad!academ!killer!jfh
From: jfh@killer.UUCP (John Haugh)
Newsgroups: comp.unix.xenix
Subject: Re: GKS, INFORMIX on SCO XENIX
Message-ID: <1043@killer.UUCP>
Date: Thu, 25-Jun-87 12:36:23 EDT
Article-I.D.: killer.1043
Posted: Thu Jun 25 12:36:23 1987
Date-Received: Thu, 2-Jul-87 02:15:18 EDT
References: <241@bvax.UUCP>
Organization: The Unix(tm) Connection, Dallas, Texas
Lines: 28
Keywords: GKS, INFORMIX, C-ISAM
Summary: Try an old PDP-11 trick

In article <241@bvax.UUCP>, rich@bvax.UUCP (Rich Chahley) writes:
> We also ran into a mitful of problems when GKS, INFORMIX C-ISAM is linked 
> together with our application software developed in-house.  The problem is
> with the stack space for the "near data segment" in XENIX.  Apparantly the
> near data segment includes the uninitialized data and string constants and
> cannot exceed 64k.
> 
> The quick work-around is to move the string constants from the application
> software out of the d-segment.  I'm not sure what the long term fix will be
> (according to SCO, a long term fix is somewhat messy and $$$).
> 
> Richard Chahley

This used to be a problem with PDP-11's.  The entire program can only be
64K period.  (Unless you use separate I&D)  Some programs would move some
of the strings into the text segment to cut down on the amount of space
that was used for all of those multiple copies of the program.  By putting
the string constants into the text segment, if the program ran shared text,
you could save a lot of memory.  I believe this was done with the shell
for exactly this reason.  Well, that or speeding up forks.  But then
I digress because of the old inews problem.

Write a sed script to change all of the .data's to .text's in whatever
file you keep your string constants in.

- John.

"90% of everything is crap." -- From your local fortune program.