Re: Re: MVT COBOL under MVS3.8j.

Dave,

I dont think youre on the right track.

When IKFCBL00 does the initial memory request, it procures what is known as
the "COBOL space". Phases are loaded in and out of the "COBOL space". The
MASTAMs are also located inside the "COBOL space". The "COBOL space" is
located in the region, of course.

The reason the phase size is so important is that the difference between
the size of the "COBOL space" and the size is of the phase is where the
MASTAMs are stored.

Example: if the "COBOL space" is 256K, and the phase size is 80K, that
leaves 170K for MASTAMs. When the compiler goes to load phase 4, it
actually packs the MASTAMs down to make sure there is enough space for the
phase.

The "fragmented core" that we are dealing with therefore is actually inside
the "COBOL space".  We need to look at why the compiler thinks this space
is "fragmented".

Joe

On Sat, Sep 14, 2019 at 9:01 AM [email protected] [H390-MVS] <
[email protected]> wrote:

>
>
> Joe,  Yep that was a typo on my part. The VER does verify for phase 4 as
> you said.
>
>
> The real problem is related to the GETALL not using any MASTAM but the
> first or second.  By just forcing the XREF phase to not acquire a third is
> as Pepe calls it a hack but it does work in at least a few instances.
>
>
> There is one place the MVT/PCP vs MVS is tested and that is related to
> memory acquisition in phase 1 during initialization.  There if running on
> MVS storage amounts are rounded to 2K boundaries.  I think this has to do
> with the merging of MASTAMs if they are contiguous.  Maybe changing the
> rounding to 4K for MVS might allow the merging to occur and prevent the
> additional MASTAM from actually occurring.  That would be an interesting
> zap to test. The problem is other GETMAINs that implicitly occur after the
> first MASTAM GETMAIN "fragment" storage such that a third MASTAM won't be
> adjacent to prior MASTAMs.  I did try to force XREF to use the third MASTAM
> but that caused a branch to TBERR4 from one of the other places in the code.
>
>
> Dave
>
> 
>