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

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 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.
 

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