Hi Tony,
Please at least pretend you looked the code I included. Does the index look too
high or too low? I'm sorry it did not get formatted correctly but clearly the
index was 0. Here it is again correctly formatted.
pgm ENTER
LA R15,0
BRANCH_ON (R15)
LBL00 LBL04
--------------------------
RETURN
Where the label's start either before column 11 or after column 16 and make
sure the "-" line covers the column your macro requires. Run it and it will
abend. The expected result would be a branch to LBL00.
I don't expect the code to be flawless. However a shared example should not be
misleading nor show an inappropriate use case.
I don't expect you to change the implementation because it's already in use and
it's your choice. I'm just curious as to why you chose AREAD over a standard
approach that provides exactly the same benefits and results.
Thanks, Jon.
On Saturday, March 9, 2019, 3:34:51 PM PST, Tony Thigpen <[email protected]>
wrote:
Jon, for me, it is a simple fact my BRANCH_ON macro makes my life a lot
easier. Which is what macros are for.
And, what "obvious abend or bad branch"?
If you are talking about the branch to A&SYSNDX if the value is too high
or too low and the programmer did not specify where to branch in such a
condition, then that is not a design flaw, but an intentionally coded
abend.
If you thing you see another 'flaw', then point it out. I never said my
code was perfect. Maybe I did not think of some error situation.
Tony Thigpen
Jon Perryman wrote on 3/9/19 4:32 PM:
> This demonstrates my point that people treat AREAD too trivially and use it
>when it's not necessary. Apparently no one really looked at the BRANCH_ON
>macro which is a production macro. There is an obvious abend or bad branch
>that the assembler would have diagnosed that AREAD hid.
>
> Tony, you are a good programmer but you ignored what I said. Surely you don't
> believe GBLC and SETC are complicated. I think you are falling into the
> Motivated reasoning trap because you want to believe in AREAD so strongly.
>
> |
> |
> | |
> Motivated reasoning
>
> The processes of motivated reasoning are a type of inferred justification
> strategy which is used to mitigate cog...
> |
>
> |
>
> |
>
>
>
>> you mentioned earlier something to the effect: "What if the macro
>> fails due to mis-use? It may cause the assembler to dump." > If you want it
>> 'safer' just use a lower ACTR value within the macro.
> Assemble & RUN the following code and tell me it doesn't abend. Don't bother
> defining the branch label in the program. While I don't have MVS, I'm
> positive it will assemble with RC=0 and produce an abend (S0Cx - invalid
> instruction). It should have failed at assembly.pgm ENTER LA R15,0
> BRANCH_ON (R15) LBL00 LBL04-----------------------
> RETURN
>
>> 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.
> "GBLC &MYCOMPANY_BRANCH_ON" and "&MYCOMPANY_BRANCH_ON SETC '&SYSNDX'" is not
> complicated. Anyone who truly finds it complicated should not use AREAD.
>
>> BRANCH_ON just makes life simpler in it's current form.
> How does BRANCH_ON with AREAD make life simpler because I still can't see it?
> I'm all for simplicity and strongly encourage it. 20 lines to support AREAD
> (including serious bugs) seems complicated compared to 4 simple SETC/GBLC
> lines. I've shown that usage is the same. If a single invocation simplifies
> life, then my previous suggestion using BRTABLE=(LABEL00,LABEL04) would be 4
> simple lines.
> Regards, Jon.
>
>
