Right... but for the CL, you want F-word alignment anyway, although it
would only cause a trivial warning if it wasn't.
As for the "oh-so-clever" remark, it only meant reusing an adcon as the
branch target... it's a very minor point; I'd just prefer something like B
*+1 or EX Rx,* that more
://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Steve Smith [sasd...@gmail.com]
Sent: Tuesday, May 4, 2021 8:40 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: [PossibleSpam] Re: AREAD question
Ah, OK
Ah, OK. If I re-coded this, there would be separate macros for each
entry. A final end-of-table macro would set an EQU to the length needed to
generate the code. The macros could easily be the same macro source, with
a type operand. But overall, I think it's simpler and clearer than to pile
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: [PossibleSpam] Re: AREAD question
There's no need for more parameters... just maybe a GBLA.
Frankly, I think branch tables are simple enough to code, including
automatic range checking, as to not be worth macros at all.
Whatever.
btw, HLASM
@LISTSERV.UGA.EDU
Subject: Re: [PossibleSpam] Re: AREAD question
AREAD is not recommended for Tony's situation. Instead, follow the standard
assembler conventions and the code will be clean and readable for assembler.
Here is how I would implement Tony's PERFORM_ON macro.
Jon.
PERFORM_ON (R3),BAD_VALUE
AREAD is not recommended for Tony's situation. Instead, follow the standard
assembler conventions and the code will be clean and readable for assembler.
Here is how I would implement Tony's PERFORM_ON macro.
Jon.
PERFORM_ON (R3),BAD_VALUE=ERRNO_2,BRTABLE=(
INITAPI, 00
ur J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
behalf of Tony Thigpen [t...@vse2pdf.com]
Sent: Monday, May 3, 2021 5:24 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: [PossibleSpam] Re: A
om: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
> behalf of Tony Thigpen [t...@vse2pdf.com]
> Sent: Monday, May 3, 2021 5:24 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: [PossibleSpam] Re: AREAD question
>
> Because the AREAD enables building the built
:24 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: [PossibleSpam] Re: AREAD question
Because the AREAD enables building the built-in error trapping logic. If
the reg is too large or negative, it's trapped automatically. And, I
don't have to remember to change the limit edits every time I add
Because the AREAD enables building the built-in error trapping logic. If
the reg is too large or negative, it's trapped automatically. And, I
don't have to remember to change the limit edits every time I add
something to the branch table.
Tony Thigpen
Steve Smith wrote on 5/3/21 5:13 PM:
Why not just have a macro to generate each entry, and not mess with AREAD
at all?
Like:
INITAPI PERF_ENT 00
ACCEPT PERF_ENT 01
...
Seems like you'd save a bunch of code, besides avoiding AREAD complications.
sas
On Mon, May 3, 2021 at 5:03 PM Tony Thigpen wrote:
> I use LOCTR heavily in my
(Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Tony Thigpen [t...@vse2pdf.com]
Sent: Monday, May 3, 2021 3:52 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: [PossibleSpam] Re
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: [PossibleSpam] Re: AREAD question
In this case, I am using AREAD to build a branch table. The macro first
edits the value passed based on the number of entries in the branch
table. It needs knows how many entries by reading branch_to points. (It
also
In this case, I am using AREAD to build a branch table. The macro first
edits the value passed based on the number of entries in the branch
table. It needs knows how many entries by reading branch_to points. (It
also builds the table while it is reading/counting the number of
entries.) The
14 matches
Mail list logo
