Failure of popen and system calls ......

[MICPRF at latvax8.lat.oz]

My problem is this - how do I stop unix system calls from failing
due to lack of space when made from a large process. I know there
is actually enough memory available, but the C library subroutines
popen and system apparently don't, despite my changing the value
of MAXMEM in <param.h> - for more info. see below.

In article <413 at latvax8.lat.oz> in aus.stats.s, I wrote:
> Anyone out there who can figure this out?
> In order to install new S on my Unix box I added another 4 Mbyte
> RAM - my system does not have paging. 
> I then installed NEW S.
> Everything works fine except for unix calls and functions that depend
> on them.
> If I install restricted new S the unix calls work fine, but I don't
> have access to all the S functions of course.
> After a failed attempt to use the unix function, for example
> after date(), or help()
> I get error messages saying call to UNIX failed : Not enough space
> or something to the effect that the UNIX call returned a status of -1
> In all cases the object last.dump contains a series of messages
> No frame available.
> I can't figure out where the problem is. I can't believe that there
> is not enough RAM as I now have 5.75 Mbyte free for S and nothing
> like that amount seems to be allocated. In any case all the other
> things seem to work ok when I run the tests. Only unix calls dont.
> Any ideas?	

A couple of people suggested I was running out of swap space - thanks
for the hint, but that wasn't the problem. I know a little more about it
now (I think), but still need advice -
I believe the problem is that the system limit on the size of a process
is set at a now unrealistically low level (~1.2 Mbytes) in /usr/include/param.h
I altered this and regenerated unix, then remade S - to no avail, and perhaps
not surprisingly (?) because the C libraries were of course compiled with
the old values in param.h. My problem now is that I don't have (wasn't
supplied with) the source code for the C libraries. The closest I can get is
to disassemble them with dis, then tweak the offending C library routines
(popen, system, and possibly fork, exec, pclose?) to fix it. Problem is
I don't even know if this approach would work and
I know nothing about assembly language.
The CPU is an M68010 based(I know its ancient)
and the operating system is AT&T Unix V.2 rel 1.1 (yes, also ancient).
When running S unix calls fail as soon as the process size gets much over
600K - this happens _very_ soon, yet the additional DRAM is nowhere near
full. If unix calls are not used the process can grow to at least 3Mbytes
without any problems - I presume here the additional memory is being
allocated with malloc and the like. My problem only arises it seems if
making unix system calls (either via popen or via system).
I believe these are checking the value of MAXMEM
(in param.h) and spitting the dummy even though there is actually enough
DRAM available.
So -
How can I get around this? Do I need to tweak the assembly for the offending
library routines? Is there another way? What should I look for in the
assembly code?
I hope this is an appropriate place to post this - don't know much
netiquette, but would be grateful for any illumination anyone might provide.

					Thanks for listening,
					Paul Fisher.
 					(micprf at latvax8.lat.oz.au).