| Newsgroups |
gmane.comp.emulators.hercules390.mvs |
| Message-ID |
<[email protected]> |
On Wed, 11 Sep 2019, Tony Harminc [email protected] [H390-MVS] wrote:
> On Wed, 11 Sep 2019 at 04:17, Giuseppe Vitillaro giuseppe-yuD/ahkh7LvrZ44/[email protected] wrote:
>
>> It looks like the compiler, when time to create
>> the symbol table comes, needs to allocate memory
>> for performing the task, but there is not any
>> large enough contiguos area available in the job
>> region.
>
> A common technique for compilers that don't know in advance how much
> work space they'll need is to issue a variable-length GETMAIN for a
> very large amount, and then FREEMAIN part of it to allow space for
> buffers and other things that either the OS or other compiler
> components will need. One wonders if the compiler is grabbing most of
> the available space, and not returning enough of it.
>
>> Mmm ... this is a COBOL compiler designed for MVT, isn't it?
>>
>> Is possible GETMAIN calls are different between MVS and MVT?
>
> MVS has many more GETMAIN options, but the MVT GETMAIN calls should
> behave entirely compatibly. In MVS the notion of REGION is rather
> different from that in MVT. In the absence of other controls (SMF,
> etc.) a GETMAIN on MVT cannot return a piece of storage larger than
> the REGION= value. On MVS, the REGION= value limits the size of any
> *single* GETMAIN, but if there is room in the private area, GETMAIN
> can be issued again and again until the private area is used up.
> (Well, in chunks the size of the GETMAIN.)
>
> But I'm not sure this is relevant to the COBOL problem. And BTW, this
> seems to be a problem in the compiler rather than a true "not enough
> storage" issue. There is no reported abend or GETMAIN failure - just a
> compiler message.
>
> Tony H.
>
True, Tony, it just nicely return RC=0016 with that obscure
message.
By the way, the manual, GC28-6399-2, page 40, specify how
to code the REGION statement for the compiler.
I've never seen used the REGION statement in this way:
REGION=(nnnnnxK[,nnnnnyK])
It looks like the second parameter "nnnnnyK" is rather
important for this COBOL compiler, but I can't understand
why.
May I ask for an explanation?
Peppe.