It surprises me that no one has pointed out that having complex tables assembled/compiled into a program is generally a Bad Idea. Almost always such tables have to be updated and that tends to require a programmer, rather than anyone with a text editor, if the tables are read into storage at program start, which generally is not going to be a significant overhead. Then one is also not limited by whatever restrictions are in the compiler/assembler.
-----Ursprüngliche Nachricht----- Von: IBM Mainframe Assembler List [mailto:[email protected]] Im Auftrag von Charles Mills Gesendet: Mittwoch, 13. Dezember 2017 18:55 An: [email protected] Betreff: Re: Address of a =LITERAL He said he did not want to have to do that. I hear you. This is an awful lot of "define the problem just so ... and lo and behold, there is no solution!" Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Jonathan Scott Sent: Wednesday, December 13, 2017 9:28 AM To: [email protected] Subject: Re: Address of a =LITERAL Ref: Your note of Wed, 13 Dec 2017 17:19:56 +0000 > Except that he wanted the literal "pooling" that the assembler's logic > provides: if you code =X'1234' twice, you only get one X'1234' literal. > Apparently he has a LOT of literal data. > > Charles If that's really necessary, one could use a SETC array to track the values defined so far for reuse. Jonathan Scott HLASM, IBM Hursley, UK
