David de Jongh wrote: | This will squander a few bytes when the program is smaller than 256 bytes
This issue is moot. The smallest program object that the binder can produce/produces is one of 4 Ki bytes. John Gilmore, Ashland, MA 01721 - USA On 8/9/12, David Stokes <[email protected]> wrote: > As other amusing psssibilities you can always use this old trick to avoid > the problem > > UNPK CS00ABND_WORK(9),TGA_TABCOD(5) Hex convert > NC CS00ABND_WORK(8),=8X'0F' > TR CS00ABND_WORK(8),=C'0123456789ABCDEF' > > which admittedly has a slight and mostly irrelevant overhead, or of course > > UNPK CS00ABND_WORK(9),CS00ABND_ABCODE(5) Hex convert > LARL R15,TRHEX > TR CS00ABND_WORK(8),0(R15) > > LARL won't be bothered by negative offsets. Of course, ensure the halfword > boundary. > > > > Alternatively > -----Ursprüngliche Nachricht----- > Von: IBM Mainframe Assembler List [mailto:[email protected]] > Im Auftrag von Paul Gilmartin > Gesendet: Donnerstag, 9. August 2012 16:02 > An: [email protected] > Betreff: Re: Printing a return code > > On Aug 8, 2012, at 12:16, Kirk Talman wrote: > >> An old technique is to use a truncated table from the days when the >> amount >> of storage used mattered. This is from a macro expansion. Often placed >> at the end of the program just after the LTORG. >> >> TRHEX EQU *-X'F0' >> DC C'0123456789ABCDEF' >> > But beware if you code: > > TR 0(8,RX),TRHEX > > which might have addressability problems in a short CSECT. > > -- gil >
