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:
>
