RE: MVT COBOL under MVS3.8j.

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] <mailto:[email protected]>  [H390-MVS] <[email protected] <mailto:[email protected]> > wrote:

  

---In [email protected] <mailto:[email protected]> , <gdblodgett@... <mailto: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.