Re: MVT COBOL under MVS3.8j.

The operation of the compiler from MVT to VS didnt change with regards to
TAMER and the XREF. This PLM matches the original MFT/MVT source exactly.

Joe

On Sat, Sep 14, 2019 at 2:22 AM 'Dave Wade' [email protected] [H390-MVS]
<[email protected]> wrote:

>
>
> Joe,
>
> The only PLM I can find is the one for OS/VS Cobol, which presumably works
> in MVS. The compiler we are using is from OS/MVT ….
>
> Dave
>
>
>
> *From:* [email protected] <[email protected]>
> *Sent:* 14 September 2019 03:13
> *To:* [email protected]
> *Subject:* Re: [H390-MVS] MVT COBOL under MVS3.8j.
>
>
>
>
>
>
> So ... a little reading from the PLM. might help here...
>
>
>
> "HOW SPACE IS ASSIGNED
>
> At the beginning of compilation, a variable
> unconditional GETMAIN is issued to get
> the main TAMER area. A MASTAM is set up for the area. If more
> space is needed later on, COBOL space is requested through
> an unconditional GETMAIN [COBOL space is the difference in
> length between the longest phase (phase 4) and the current
> phase]. If the COBOL space obtained is contiguous
> to an old TAMER area. it is considered part ·of that TAMER area and the
> old MASTAM is then updated.
>
> If the next phase to process is not larger than the current phase.
> the COBOL space is kept. Since this space is kept only three MASTAMs are
> required. If the next phase to process is larger than the
> current phase, the tables that are to be passed between phases are packed
> and moved so that none of them are overlaid by the next phase.
>
> Within a TAMER area (and as indicated in the MASTAM), the tables start in
> lowest storage and the dictionary starts in highest storage. The TAMMs for
> the MASTAM are assigned contiguously within the TAMM block, and their order
> reflects the storage order of the tables to which they point.
>
> Note: If several GETMAINs are issued, the areas obtained will
> usually be in low storage so that only one MASTAM will be used."
>
>
>
> Now look at the GETALL routine used by phase 6A (XREF):
>
>
>
> "Routine GETALL is called by phases 6 and 6A. Its function is to provide
> space for a table that may be in excess of 32K bytes, the normal
> maximum size. It is a request for all available table space in a contiguous
> area. The tables are packed and, if all available COBOL space has not
> yet been acquired, a GETMAIN macro instruction is issued for the
> remainder. The largest unused, contiguous area is found, and its starting
> address and length are passed back to the calling phase in registers 0
> and 1, respectively.
>
> All subsequent use of that area is handled internally by the phase that
> called GETALL, since a call to TABREL is the only TAMER call which
> may legitimately follow a call to GETALL in the same phase. At the end
> of the phase that called GETALL, the area then becomes available for normal
> phase 00 table-handling procedures."
>
>
>
> Joe
>
>
>
> On Fri, Sep 13, 2019 at 8:24 PM kerravon86-/[email protected] [H390-MVS] <
> [email protected]> wrote:
>
>
>
> ---In [email protected], <gdblodgett@...> wrote :
>
> > I'm out of town at the moment, so I can't
> > check the source.
>
> If I make ikfcbl00.txt available on the web,
> can you access that?
>
> > why it thinks memory is too fragmented.
>
> I saw this code, containing the only GETMAIN:
>
> GETMAIN R,LV=(0) 45100021
> L R15,TBAPRIME 45120021
> ST R1,GETTABLE+NX28 45140021
> LR R0,R6 45160021
> * 45180021
> * TEST IF NEW AREA IS CONTIGUOUS TO AN OLD ONE. 45200021
> * 45220021
> LA R6,TBMASTAM GET FIRST MASTAM. 45240021
> LR R9,R1 45260021
> AR R9,R0 45280021
> TBGET06 C R9,TBDBEGAR(R6) 45300021
> BE TBGET05 LOW CORE CONTIGUITY. 45320021
> L R10,TBDBEGAR(R6) 45340021
> A R10,TBDLENG(R6) 45360021
> CR R1,R10 45380021
> BE TBGET55 HIGH CORE CONTIGUITY. 45400021
> C R6,TBLASMTM 45420021
> BE TBGET07 NO CONTIGUITY AT ALL. 45440021
> LA R6,TBMSTMLG(R6) 45460021
> B TBGET06 TRY NEXT AREA. 45480021
> SPACE 2 45500021
> * NO CONTIGUITY - SET A NEW MASTAM. 45520021
>
> It seems that it is trying to join GETMAIN
> areas together. But isn't there some
> overhead placed before each GETMAINed
> block? Perhaps in MVS, but not in MVT?
> I don't think a user application can join
> memory areas together in MVS.
>
> BFN. Paul.
>
>
>
>
> 
>