Addressability is much less of an issue than it was on S/360. Just how big are
you csects?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Ed Jaffe
On 11/9/2021 9:55 AM, Seymour J Metz wrote:
LOCTR may not help with literals, but it can help with macros that generate a
DC. Instead of branching around the constant, put a LOCTR before and after it.
There is no guarantee a existing USING is in place for a literal or DC
in a given LOCTR.
LOCTR may not help with literals, but it can help with macros that generate a
DC. Instead of branching around the constant, put a LOCTR before and after it.
From: IBM Mainframe Assembler List on behalf
of Peter Relson
Sent: Tuesday, November 9, 2021
In a huge number of cases, programs using relative branch are not
base-less. They have no "code base register" but that does not mean they
are base-less.
For the most part, z/OS has simply decided that we will not worry about
"no base register at all" cases when customers use our macros. We
Martin Ward wrote:
> > No space is wasted except, possibly, at the origin of the pool, and
> > in aligning to the start of the statement following the literal
> > pool.
>
> So this isn't entirely correct: the last segment may have padding bytes.
A documentation update was included in APAR PH34824
On 09/11/2021 08:53, Jonathan Scott wrote:
It is still stored within the last section of the literal pool
(because at the time of definition, it is not necessarily known
whether it will be referenced by relative address)
Given that it has an odd length, it cannot be stored in the forth
APAR PH34824 in March 2021 fixed the LARL loophole; if a literal
with odd byte length is referenced by relative address, it is
now automatically aligned to a halfword by inserting a padding
byte before it if necessary.
It is still stored within the last section of the literal pool
(because at the
