Jon,
> I would love to understand how AREAD is so significant.
It comes down to both macro simplicity and usage simplicity.
Code a replacement macro using your method. You will find that macro
will be much more complicated as how it handles the A&SYSNDX and
C&SYSNDX labels. You now have to use GLBx values to pass information.
Also, you mentioned earlier something to the effect: "What if the macro
fails due to mis-use? I may cause the assembler to dump." Not actually
true. I have coded this macro wrong by accident and the worse thing that
happened was that the assembler quit due to exceeding the max macro loop
count. If you want it 'safer' just use a lower ACTR value within the macro.
I have many macros that paths such as your suggest "BRANCH_ON END", so I
know how to code one. BRANCH_ON just makes life simpler in it's current
form.
I like my code simple. That's why I have written some of my other
'simple' macros:
BITON
BITOFF
BCTZ
LTLF
LTLH
An assembler bigot would say" "If they don't know how to code the one
instruction to set a bit off, then they should not be coding assembler."
I believe that using the macro facilities for minor error-prone coding
is just as important as using it to generate complex code. It also makes
the code easier to read when looking for a bug.
Tony Thigpen
Jon Perryman wrote on 3/9/19 12:45 AM:
Thanks Tony, This new example demonstrates a valid use for AREAD. It does not
have any executable code and it clearly has benefits over using assembler.
I would love to understand how AREAD is so significant. Is there still anyone who
disagree's with my statement "Never use AREAD unless it's really needed and you are
willing to code it correctly"? If so, how would how would the OP use AREAD to create
his tables without jumping thru hoops? Nothing complicated nor complete. Just to refresh,
he basically wants to emulate the old style CICS transaction table? A short description
telling me how it works would suffice. Remember that you lose parser, default and syntax
processing that must be provided in the AREAD macro or resort to RPG style coding.
As for the BRANCH_ON macro, what is the benefit of AREAD over not using it. How
is
BRANCH_ON (R15) --- using AREAD
label00
label04
----
better than
BRANCH_ON (R15) --- with AREAD code deleted
B label00
B label04
BRANCH_ON END
considering that the AREAD implementation was simple because validation is
missing, why is it better than letting the assembler do all the work for you?
You can't even easily call the AREAD implementation from another macro. I would
love to understand why it has such a committed following.
Thanks, Jon.
On Friday, March 8, 2019, 5:49:58 PM PST, Tony Thigpen <[email protected]>
wrote:
Jon, I was trying to show a very basic use of AREAD, something so the OP
had something of an example.
Back to the OP's question, where he wanted to build a large table. I
have attached an example of just that using AREAD. It's from one of my
message programs. I have striped out the program code and just left the
macro, the dsect for the final table, and the input to the table. One
major advantage over individual macro calls is that I can fit everything
for each message in one line. With a macro call, each entry would take
at least two lines and have to have the right continuation syntax.
This is my fifth attempt to post the example. I had to delete several
hundred lines of input to the macro because the size of the email
exceeded the list max. I also had to remove some of the quoted text.
My Branch_On macro is simplistic, but one of the key things it does is
verify that the subscript passed is within range, even if I added more
possible outcomes. I have some programs that branch based on over a 100
possible index values. And, some random index values in the middle are
invalid. Since IBM keeps adding more values, with my BRANCH_ON, I can
just add another branch pointer and not worry about changing all the
edits. And, with 100's of entries, it's a lot less typing that keying a
macro call on each line of the program. Basically, it makes my life a
lot simpler.
Tony Thigpen
Jon Perryman wrote on 3/8/19 5:21 PM:
How is your BRANCH_ON macro improved by AREAD? You chose BRANCH_ON because it
was a simpler macro but you have correctly coded AREAD macro's.
Regards, Jon.
On Friday, March 8, 2019, 2:00:50 AM PST, Tony Thigpen
<[email protected]> wrote:
