[Info-vax] Process memory settings

[Syltrem]

"Syltrem" <syltremzulu at videotron.ca> wrote in message 
news:AwUgm.549222$Tp1.144878 at en-nntp-01.dc1.easynews.com...
>
> "John Reagan" <johnrreagan at earthlink.net> wrote in message 
> news:jPSdncSMSZfA6h7XnZ2dnUVZ_vadnZ2d at earthlink.com...
>>
>> "Syltrem" <syltremzulu at videotron.ca> wrote in message 
>> news:zgGgm.528664$4p1.6371 at en-nntp-03.dc1.easynews.com...
>>>
>>> And the program... well I didn't want to get into that and reveal it... 
>>> It's the Cobol compiler.
>>> Syltrem
>>
>> Can you share the OS architecture, the OS version, and the compiler 
>> version number please?  My magic 8-ball is in the shop.
>>
>> Are you moving from Alpha to I64 perhaps?  The I64 compilers use more 
>> memory than their Alpha cousins.  The increased number of instructions, 
>> nops, bundling, etc. which are all in memory during the compilation can 
>> push compilations that work on Alpha [just barely] to ones that won't 
>> compile at all on I64.  There really isn't a magic switch to make things 
>> "better". Using /NOOPT often makes it worse since you'll get even more 
>> instructions hanging around in memory waiting to be written to the object 
>> file.  Breaking up the module into smaller modules is just about the only 
>> choice.
>>
>> All the compilers are 32-bit applications.  If they run out of P0/P1, 
>> you're done.  You can bump pagefile quota all you want, but it won't 
>> magically make the compilers start using 64-bit pointers and 64-bit 
>> address space.
>>
>> [Yes, we did look at making the change, the trying to track down the 
>> number of pointers to expand; fields to change; etc. was way too risky.]
>>
>> John
>>
>>
>>
>
> Hi John
>
> Maybe this is it, the 32 bit address space. But it does compile on a 
> VAX...
>
> Also if that helps, no matter what parameter I change (PGFLQUO, WSEXTENT 
> etc) the SHOW PROC/QUO will always show this after the compiler exits :
>
> Peak working set size:     645568
> Peak virtual size:         845664
>
>
> And I cannot increase the max authorized WS so that "Peak virtual size" 
> can go higher. Why can't I increase it ? Where is this value derived from 
> ?
>
> Thanks
> Syltrem
>
>
>
>

I tried a few more things:

COBOL/NOOBJECT
This is not very helpful to me, but it does complete successfully so tells 
the the source code is ok and compiler optimization can be done.

COBOL/NOPTIMIZE also completes successfully. Better.

COBOL/OPTIMIZE=LEVEL=1 fails.

Though I now have something usable, if not optimal, I'd still want to 
understand how to increase the working set, if someone knows.

Merci
Syltrem