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

"'Shelby Beach' [email protected] [H390-MVS]" <[email protected]>
Newsgroups gmane.comp.emulators.hercules390.mvs
Message-ID <1F2C1A877EF24E8EBA04B0779230EAC9@SacZ800>
Hi Dave,
 
With regards to the VM question, I would think that since VM (or I guess
it's actually CMS) is providing all kinds of MVT/MVS support to allow the
compilers to run, any similarity with regards to storage
layout/fragmentation under VM vs. MVS would be purely coincidental. So when
the compiler is (falsely ?) seeing fragmentation in the MVS environment,
things are far different under VM.
 
Shelby
 


  _____  

From: [email protected] [mailto:[email protected]] 
Sent: Saturday, September 14, 2019 11:56 AM
To: [email protected]
Subject: Re: [H390-MVS] 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.