[Info-vax] Process memory settings

[JBloggs]

On Thu, 13 Aug 2009 17:05:48 -0400, "Syltrem"
<syltremzulu at videotron.ca> wrote:

>
>"John Reagan" <johnrreagan at earthlink.net> wrote in message 
>news:jredndZhO4aG8BnXnZ2dnUVZ_h-dnZ2d at earthlink.com...
>>
>> "Syltrem" <syltremzulu at videotron.ca> wrote in message 
>> news:74Zgm.530414$4p1.384312 at en-nntp-03.dc1.easynews.com...
>>>
>>> With the new compiler 2.9 Peak virtual size goes up to 1964832 and is no 
>>> longer limited to 847968, but it still fails in the end even when I 
>>> haven`t used up my page file quota.
>>>
>>
>> There is only 1GB of P0 space regardless of page file quota, pagefiles, 
>> working set, day of week, phase of moon, etc.  When you hit that limit, 
>> LIB$GET_VM (which is what the compiler uses to allocate memory) will 
>> return an error.  You cannot put 10 pounds of er, bits in a 5 pound bag.
>>
>> If you have a COBOL program that causes the compiler to allocate memory 
>> until it dies at /OPT=LEVEL=1, then the compiler team would like to see 
>> it. In the meantime, you have /NOOPT as a workaround.
>>
>> John
>>
>
>That's probably what I should do - open a case with HP.
>Or I'll live with /NOOPT. Users will be happy anyway, going from a slow VAX 
>to an Alpha they'll never notice.
>
>Thanks
>Syltrem
>

This suggestion might be along the lines of throwing stuff
at the wall, and seeing what sticks, but you might look at what 
files are getting opened (and closed?)  during the compile.  
($set watch/class=mumble  FILE) 

I'm thinking along the lines of a recursive include, or 
whacked directory and/or search path.

One project I worked on in the distant past, (written in C)
MMS often had in excess of 8000 files open (peak), 
 most of them were  include files.  (COBOL != C. but you get the idea)