mdella@polyslo.CalPoly.EDU (Marcos R. Della) (12/09/88)
I posted this a few days ago, but so far have heard nothing. I was wondering is SOMEONE out there has gotten the pathalias9.1 program to work on a 16 bit machine. I am running SCO xenix and have not been able to get it to work at all without the out of memory errors. I tried putting the -Mh and/or the -LARGE -M2l options in the compiler line, but I keep getting memory mismatches when compiling the thing together... Any clues? Any help on what needs to be changed for a xenix box? HELP!!! Marcos Della marcos@borlnd -- ..!csustan ->!polyslo!mdella | mdella@polyslo | Whatever I said doesn't ..!sdsu ---/ Marcos R. Della | (805) 543-0135 | mean diddly as I forgot ..!csun --/ 225 N. Chorro St / it even before finishing ..!dmsd -/ San Luis Obispo, CA 93401 / typing it all out!!! :-)
root@libove.UUCP (Jay M. Libove) (12/13/88)
From article <6608@polyslo.CalPoly.EDU>, by mdella@polyslo.CalPoly.EDU (Marcos R. Della): > I was wondering is SOMEONE out there has gotten the pathalias9.1 program > to work on a 16 bit machine. I am running SCO xenix and have not been > able to get it to work at all without the out of memory errors. I > tried putting the -Mh and/or the -LARGE -M2l options in the compiler > line, but I keep getting memory mismatches when compiling the thing > together... Any clues? > Any help on what needs to be changed for a xenix box? chip@ateng.UUCP has modified pathalias v9 to run on SCO Xenix machines, but unfortunately the map has grown to the point where even his extensive and amazing modifications can't grow pathalias enough to swallow the map as it is. On my machine (libove.UUCP) the same pathalias binary that used to work now runs almost to completion, and then freezes; I think it hits the top of memory (my system has 2048K, with 1402K as the maximum user process size) and tries to swap. Maybe it is a system bug. In any case, until someone can come up with a more memory efficient method of processing the maps, SCO Xenix 2.2.1 (80286) sites with 2MB or less of memory won't be able to process the whole map. *SIGH* I do hope that someone can prove me wrong! -- Jay Libove ARPA: jl42@andrew.cmu.edu or libove@cs.cmu.edu 5731 Centre Ave, Apt 3 BITnet: jl42@andrew or jl42@drycas Pittsburgh, PA 15206 UUCP: uunet!nfsun!libove!libove or (412) 362-8983 UUCP: psuvax1!pitt!darth!libove!libove
chip@ateng.ateng.com (Chip Salzenberg) (01/10/89)
According to root@libove.UUCP (Jay M. Libove): >chip@ateng.UUCP has modified pathalias v9 to run on SCO Xenix machines, >but unfortunately the map has grown to the point where even his extensive >and amazing modifications can't grow pathalias enough to swallow the map >as it is. My mods still work! I'm using pathalias to this day on Xenix/286. >I think it hits the top of memory (my system has 2048K, with 1402K as >the maximum user process size) and tries to swap. Maybe it is a system bug. Well, I have 3.5M. Perhaps that's it. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
jbayer@ispi.UUCP (Jonathan Bayer) (01/10/89)
In article <1989Jan9.134250.27793@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes:
=According to root@libove.UUCP (Jay M. Libove):
=>chip@ateng.UUCP has modified pathalias v9 to run on SCO Xenix machines,
=>but unfortunately the map has grown to the point where even his extensive
=>and amazing modifications can't grow pathalias enough to swallow the map
=>as it is.
=
=My mods still work! I'm using pathalias to this day on Xenix/286.
=
=>I think it hits the top of memory (my system has 2048K, with 1402K as
=>the maximum user process size) and tries to swap. Maybe it is a system bug.
=
=Well, I have 3.5M. Perhaps that's it.
Funny. I have pathalias working on a 2 meg machine. It currently
takes about 10-15 minutes to chew on the maps, but it works fine.
Perhaps it is the fact it is running on a 386 that makes it work.
--
Jonathan Bayer "The time has come," the Walrus said...
Intelligent Software Products, Inc.
19 Virginia Ave. ...uunet!ispi!jbayer
Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispimichael@roberta.UUCP (Michael A. Moran ) (01/11/89)
In article <1989Jan9.134250.27793@ateng.ateng.com>, chip@ateng.ateng.com (Chip Salzenberg) writes: > > >I think it hits the top of memory (my system has 2048K, with 1402K as > >the maximum user process size) and tries to swap. Maybe it is a system bug. > > Well, I have 3.5M. Perhaps that's it. And you are very close to the limit where pathalias will fail. Running Xenix on a '286 with 3 Megs I can build a pathalias file with about 9800 sites. With 2.5 Megs I can build a pathalias file with about 7500 sites. There are about 11,000 sites (if I remember correctly) registered with the UUCP mapping project (although there are more sites because many are not registered). This would put a 3.5Meg system near the point where pathalias can't handle all the sites. In any event, all other things being equal I can build a larger pathalias file with more memory, but still must drop some foreign countries when I only have 3 Megs, and must drop some domain sites when I only have 2.5 Megs installed. -- Michael A. Moran { ...}!comix!roberta!michael {uunet, pyramid, ...}!vdx!roberta!michael
jim@tiamat.FSC.COM (Jim O'Connor) (01/12/89)
In article <404@ispi.UUCP>, jbayer@ispi.UUCP (Jonathan Bayer) writes: > In article <1989Jan9.134250.27793@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: > =>I think it hits the top of memory (my system has 2048K, with 1402K as > =>the maximum user process size) and tries to swap. Maybe it is a system bug. > = > =Well, I have 3.5M. Perhaps that's it. > > Funny. I have pathalias working on a 2 meg machine. It currently > takes about 10-15 minutes to chew on the maps, but it works fine. > Perhaps it is the fact it is running on a 386 that makes it work. If you are running Xenix 386 with a decent swap area, you're maximum user process size could be as large as several MB (I've got 2 meg ram and a max user proc size of over 5 meg due to large swap area; call it paranoia). That's the beauty of demand-paged virtual memory. It's only the 80286 machines (or perhaps 386 machines running 286 Xenix) that have these major memory problems. --jim ------------- James B. O'Connor jim@FSC.COM Filtration Sciences Corporation 615/821-4022 x. 651
debra@alice.UUCP (Paul De Bra) (01/12/89)
In article <404@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: >... >Funny. I have pathalias working on a 2 meg machine. It currently >takes about 10-15 minutes to chew on the maps, but it works fine. >Perhaps it is the fact it is running on a 386 that makes it work. The 386 makes all the difference. On the 286 you can only swap whole processes, meaning that you cannot have a process that is larger than your physical memory minus the kernel. On a 2Mbyte machine that is less than 1.5Mbyte in most cases. When you boot the machine it will tell you what the largest process size is. On the 386 you have virtual memory, meaning that you can have processes of which only a part is in physical memory and the rest is in the swap- space. A process can usually be larger than your physical memory too. The maximum process size is determined by sizes of system tables and by the size of your swap space, but not by the amount of ram. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (01/13/89)
I am trying to understand why so much memory is needed to build the
database. I build everything on my 386 system, every entry in the world
plus all of the domains. Looking at the accounting records I see that
the process tops out at about 1.4MB. Since that fits nicely in memory
there's no question of paging be involved.
Can someone shed some light on why the 286 needs more memory? I used to
build a reasonably large subset on a 2MB AT until I moved the job to the
386 (for speed).
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -memem@zinn.MV.COM (Mark E. Mallett) (01/16/89)
In article <146@roberta.UUCP> michael@roberta.UUCP (Michael A. Moran ) writes: >In article <1989Jan9.134250.27793@ateng.ateng.com>, chip@ateng.ateng.com (Chip Salzenberg) writes: >> >> >I think it hits the top of memory (my system has 2048K, with 1402K as >> >the maximum user process size) and tries to swap. Maybe it is a system bug. >> >> Well, I have 3.5M. Perhaps that's it. > >And you are very close to the limit where pathalias will fail. Running Xenix >on a '286 with 3 Megs I can build a pathalias file with about 9800 sites. >With 2.5 Megs I can build a pathalias file with about 7500 sites. My problem with pathalias is not in how much memory I have (by the way, 3.5 megabytes for 11,000 nodes works out to over 300 bytes per node: I hope that pathalias doesn't have that kind of overhead). Recent breakdowns in my pathalias processing caused me to look at the source. It (pathalias) allocates symbol tables as big monolithic arrays of pointers to elements. When a table gets full, a bigger one is allocated and the smaller table is copied into it. The problem is that my Microport System V/AT system doesn't support allocation of bigger than 64K blocks, yet the situation has reached the point where pathalias has tried to expand to an array that takes 84K. Pushed into the 16 bit int for call to malloc, very bad things happen. My though has been to try to rewrite the symbol management to accomodate this restriction. If anyone has already done it, please drop me a note. I'm cross-posting this over to microport, where it probably has more relevance (in my situation). Thanks, -mm- -- Mark E. Mallett Zinn Computer Co/ PO Box 4188/ Manchester NH/ 03103 Bus. Phone: 603 645 5069 Home: 603 424 8129 BIX: mmallett uucp: mem@zinn.MV.COM ( ...{decvax|elrond|harvard}!zinn!mem ) Northern MA and Southern NH consultants: Ask me about MV.COM
tif@cpe.UUCP (01/17/89)
/* Written 10:00 pm Jan 15, 1989 by zinn.UUCP!mem in cpe:comp.unix.xenix */ >is allocated and the smaller table is copied into it. The problem is >that my Microport System V/AT system doesn't support allocation of bigger >than 64K blocks, yet the situation has reached the point where pathalias >has tried to expand to an array that takes 84K. Pushed into the 16 >bit int for call to malloc, very bad things happen. Check to see if you have something called proctl(). Xenix had it and one of the options was to grab a "large" piece of ram to be used with a "huge" pointer. (Warning: I've never used the call.) Paul Chamberlain Computer Product Engineering, Tandy Corp. {killer | texbell}!cpe!tif