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

Same question ;-) Peppe.

On Thu, 25 Sep 2019, sccosel-/[email protected] [H390-MVS] wrote:

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