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

On Sat, 14 Sep 2019, [email protected] [H390-MVS] wrote:

> This is what we have at entry to FREEALL as phase 6A starts for the three MASTAMs without zap.  In the second MASTAM you have about 22K free (X'5800') had we not acquired #3 XREF has no problem running.  I could be wrong on the merging across MASTAMs, just was reading some comments in the code and thinking about the successful compile question as to why on VM.  Couldn't find anything in the source code about VM.
> TBMASTAM DC    1F'0'     BEG.OF AREA.
>         DC    1F'0'     LENGTH OF AREA
>         DC    1F'0'     CURRENT FIRST FREE BYTE FOR TABLE.
>         DC    1F'0'     REMAINING LENGTH.
>         DC    A(TBTAM)       FIRST TAM FOR THIS MASTAM.
>         DC    A(TBTAM+TBTAMLG)  NEXT TAM TO BE FOR THIS MASTAM.
>         DC    1F'0'     NUMBER OF DICT. SECTION IN THIS MASTAM.
>         DC    14F'0'   2 OTHER MASTAMS
>
> Begin    Length   1st Free Amt Free 1st TAM  Next TAM Num Dict
> 00010000 00007C00 00010100 00007B00 00009A7C 00009A88 00000001
> 00020000 00005800 00020000 00005800 00009A88 00009A88 00000000
> 00019000 00006000 00019000 00006000 00009A88 00009A88 00000000
> Last SVC A trace entry for this just before SVC 13 U16 abend trace entry.
>
>
> So I wrote this simple COBOL code with lots of simple PIC X fields. 
> Turns out if there is more than 2046 (interesting number) lines of code

Yep, somewhere 11 bits are watching ;-)

> before the PROCEDURE DIVISION the compiler S0C4.  I have 18,000 MOVE 
> statements in PROCEDURE DIVISION with no problem.  XREF runs 
> successfully with some fields having 999 references and some having 
> none.  Does take over 1 minute CPU to run compile plus I also request 
> DMAP and PMAP.  I uploaded it for reference.
>
>
> I think the fragmented message is really misleading in this case since 
> it isn't fragmented.  I am just guessing the adding of the third MASTAM 
> as the last one should not occur.

It looks like the compiler is performing "suballocation", how we would
call it in the UNIX/C environment, like what is done by malloc/calloc
after an sbrk().

It may be that the original programmer thought, working under MVT,
blocks are always allocated contiguosly in memory, while under MVS
are not?

I mean two consecutive GETMAINs alwayas return contiguos blocks
under MVT and VM/370?

If this would be the case, the original programming logic didn't
need to merge blocks, after GETMAIN.

It would need under MVS.

>
>
> As for Pepe's reference to hacking,  that's exactly what the zap is....

Well, we agree ;-)

Peppe.