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

"sccosel-/[email protected] [H390-MVS]" <[email protected]>
Newsgroups gmane.comp.emulators.hercules390.mvs
Message-ID <[email protected]>
Is the consensus that the zap below, is the best fix for the Cobol XREF issue?
 

 ScottC

---In [email protected], <davekreiss@...> wrote :

 I got to thinking why is there a request for more space in GETALL since there is lots of free space. 
 TBGETALL DS    0H                                            
         TM    TBSWGENE,TBSPASKD                             
         BO    TBGTAL10            YES - BYPASS GETMAIN      
         BAL   R14,TBGETSPC        ASK FOR COBOL SPACE       
TBGTAL10 BAL   R14,TBPACKGN        PACK ALL MASTAMS          
         LA    R4,TBMASTAM                                   
         C     R4,TBLASMTM                                   
         BE    TBGTAL21            ONLY 1 MASTAM             
         LA    R5,TBMSTMLG(R4)                               
         C     R5,TBLASMTM                                   
         BNE   TBERR4              R5 NOT EQUAL TO TBLASMTM  
 So I zapped the call to TBGETSPC to a NOP and that also allows the XREF phase to run.
 I think the logic of thinking merging MASTAM can happen is flawed on MVS since there are so many places in system code (especially access methods) which get storage (like OPEN for buffers for example).  The net result is getting two pieces of storage at different times and hoping they will be contiguous is very unlikely to happen. 
 So this zap also works and is probably better than the prior largest phase zap.  A real fix might be to allow the XREF phase to use the third MASTAM.  That might be more work than it is worth.  This zap may encounter problems on a very large program who knows..
  NAME IKFCBL00 PH0TBST1         
  VER 070E 45E0B4F6               BAL   R14,TBGETSPC
  REP 070E 4700B4F6               NOP   TBGETSPC              

 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.