This is really a simple problem to solve. Here is a sample "data" program that
I believe satisfies the OP's needs:
MACRO
&LBL LITADCON &LIT
DATAAREA LOCTR ,
L&SYSNDX DC &LIT
&SYSECT LOCTR ,
&LBL DC A(L&SYSNDX)
MEND
TESTPGM CSECT ,
DATAPTR1 LITADCON C'1234'
DATAPTR2 LITADCON C'5678'
DATAPTR3 LITADCON C'9012'
DATAPTR4 LITADCON C'3456'
END TESTPGM
And here is what gets assembled. Note that all literals are placed after all
the main CSECT "code", no LTORG needed.
Loc Object Code Addr1 Addr2 Stmt Source Statement
1 MACRO
2 &LBL LITADCON &LIT
3 DATAAREA LOCTR ,
4 L&SYSNDX DC &LIT
5 &SYSECT LOCTR ,
6 &LBL DC A(L&SYSNDX)
7 MEND
000000 00000 00020 8 TESTPGM CSECT ,
9 DATAPTR1 LITADCON C'1234'
000010 00010 00020 10+DATAAREA LOCTR ,
000010 F1F2F3F4 11+L0001 DC C'1234'
000000 00000 00020 12+TESTPGM LOCTR ,
000000 00000010 13+DATAPTR1 DC A(L0001)
14 DATAPTR2 LITADCON C'5678'
000014 00010 00020 15+DATAAREA LOCTR ,
000014 F5F6F7F8 16+L0002 DC C'5678'
000004 00000 00020 17+TESTPGM LOCTR ,
000004 00000014 18+DATAPTR2 DC A(L0002)
19 DATAPTR3 LITADCON C'9012'
000018 00010 00020 20+DATAAREA LOCTR ,
000018 F9F0F1F2 21+L0003 DC C'9012'
000008 00000 00020 22+TESTPGM LOCTR ,
000008 00000018 23+DATAPTR3 DC A(L0003)
24 DATAPTR4 LITADCON C'3456'
00001C 00010 00020 25+DATAAREA LOCTR ,
00001C F3F4F5F6 26+L0004 DC C'3456'
00000C 00000 00020 27+TESTPGM LOCTR ,
00000C 0000001C 28+DATAPTR4 DC A(L0004)
000000 29 END TESTPGM
HTH
Peter
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]] On
Behalf Of Charles Mills
Sent: Wednesday, December 13, 2017 9:55 AM
To: [email protected]
Subject: Re: Address of a =LITERAL
EXTERNAL: This email originated from outside of Broadridge. Do not click any
links or open any attachments unless you trust the sender and know the content
is safe.
Glad you find it potentially useful.
> isn't it a bit too clever...?
Well, as I said in the last sentence of my first paragraph it is too clever for
me to use, but only you know the tradeoffs for you versus some other less than
perfect solution. Document it well, put the 123 below into a macro -- perhaps
it is not too bad.
> Is the 64K limit sufficient for the foreseeable future?
I would hope so, but only you would know.
Charles
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]] On
Behalf Of Windt, W.K.F. van der (Fred)
Sent: Tuesday, December 12, 2017 10:43 PM
To: [email protected]
Subject: Re: Address of a =LITERAL
> I don't know why I keep thinking about this but I believe I have a
> solution. It will give you exactly what you wanted, effectively DC
> A(=literal). It is a hack and a kludge and I would not do it myself, but I
> believe it will work.
>
> A. Add a separate CSECT to your code following the record layout.
> Let's call it LITCSECT. Ahead of your table establish addressability
> on it with USING LITCSECT,0. Put a LTORG in the CSECT. That will
> collect all of your literals in that CSECT.
>
> B. In your table, a three-step process. You might want to put this in
> a macro to avoid screwing it up. At each spot that you want your literal
> pointer:
>
> 1. DC A(LITCSECT)
>
> That will generate an RLD so that whatever gets assembled into the
> word, at load time MVS will add the load address of LITCSECT to it.
>
> 2. ORG *-4
> LA 0,=literal
>
> That will (a.) generate your desired literal following LTORG in
> LITCSECT; and
> (b.) overlay the A(LITCSECT) with 41000xxx where xxx is the offset of
> the generated literal into LITCSECT.
>
> 3. ORG *-4
> DC X'0'
> ORG *+3
>
> That will get rid of the 41.
>
> So you now have 00000xxx in the table, where xxx is the offset of the
> literal into LITCSECT, and an RLD that at load time will relocate the
> word by the address of LITCSECT.
>
> QED
Yup, that's creative but the 12 bits of offset are not sufficient: we have
large structures with long element names that require more that 4K in the
literal pool.
I could get even more creative and add more USING statements and use R0 for the
first 4K of the literals, R1 for the next 4K etc. That way the S-part in the LA
instruction end up creating a 16 bit offset into the literal pool. With 16
USINGs I can cover 16 * 4K = 64K of literals. That is more than enough for any
conceivable structure. And it's perfectly feasible to use every register to
cover a large literal pool because we are generating load modules that only
contain this datastructure. There is no executable code whatsoever in these
modules so the macros currently don’t use any base register anyway.
I have to look at the pros and cons and maintainability: it's very clever and I
don't have to implement my own version of a literal pool in the macros but
isn't it a bit too clever...? Is the 64K limit sufficient for the foreseeable
future? These kinds of limits come back to haunt you much sooner than you ever
thought possible.
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
