Re: Best practice using Conditional Assembly
Jon, If you are fussing about the fixed-format of the input, then WTF. It's use, by design, requires a fixed format input deck. It's documented that way and if someone uses it wrong, then they are responsible for the outcome. I work with programmers that can follow direction and use thing right. But, even if they do it wrong, then the worse outcome, if the '-' line is wrong, is a message from the assembler that the loop count is exceeded. No big problem. It get's fixed and they move forward. If other lines are not in the correct position, they get assembler errors. Again, not a big problem. Just because you don't like a fixed format input deck, does not mean that the design is flawed or wrong. It's just a style you would not implement but I will. Are you also going to complain that the branch labels are restricted to 24 characters? That is the biggest complaint I have had with the macro from my people. Tony Thigpen Jon Perryman wrote on 3/9/19 10:37 PM: Sorry, darn yahoo Email and how listserv handles formatting. Here's another try at getting it right. pgm ENTER LA R15,0 BRANCH_ON (R15) LBL00 LBL04 -- RETURN On Saturday, March 9, 2019, 7:32:41 PM PST, Jon Perryman wrote: 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
Re: Best practice using Conditional Assembly
OMG. "RUN THE EXAMPLE". I asked you to run it 3 times now. It obviously doesn't branch to the LBL00. Instead, it abends. Totally unacceptable except for personal use. > That is the biggest complaint I have had with the macro from my people. You should be ashamed having others use this macro. This must be a nightmare for your QA people. You couldn't be bothered to use AREAD correctly. Don't use AREAD unless it's needed and you are willing to code it correctly. I've never complained about all the things you keep saying are my complaints. I'm complaining that a macro SHARED with us (and used in your production) has blatantly obvious bad branches when a label is in the wrong column. > Considering that the one that told me to use AREAD, including providing > the > base examples, was John Ehrman, I think I will take his opinion over yours. John would never recommend this as a correct use of AREAD. Apparently you never asked when NOT to use AREAD. You never asked why IBM avoids using AREAD in their macro's. I would expect his examples to be for data generation and very rarely for code generation. > so the OP had something of an example. I don't expect examples to be flawless. However, I do expect them to be presentable and something they can actually use as a model. I've tried several times to help you understand so this is my last attempt. Regards, Jon. On Sunday, March 10, 2019, 3:50:15 AM PDT, Tony Thigpen wrote: Jon, If you are fussing about the fixed-format of the input, then WTF. It's use, by design, requires a fixed format input deck. It's documented that way and if someone uses it wrong, then they are responsible for the outcome. I work with programmers that can follow direction and use thing right. But, even if they do it wrong, then the worse outcome, if the '-' line is wrong, is a message from the assembler that the loop count is exceeded. No big problem. It get's fixed and they move forward. If other lines are not in the correct position, they get assembler errors. Again, not a big problem. Just because you don't like a fixed format input deck, does not mean that the design is flawed or wrong. It's just a style you would not implement but I will. Are you also going to complain that the branch labels are restricted to 24 characters? That is the biggest complaint I have had with the macro from my people.
Re: Best practice using Conditional Assembly
On 2019-03-10, at 04:50:11, Tony Thigpen wrote: > > If you are fussing about the fixed-format of the input, then WTF. It's use, > by design, requires a fixed format input deck. ... > That's painfully archaic. > Just because you don't like a fixed format input deck, does not mean that the > design is flawed or wrong. It's just a style you would not implement but I > will. > In this era of large-screen terminals, the user should be given a choice. -- gil
Re: Best practice using Conditional Assembly
In this case, it's not archaic. Column 16 is the standard assembler continuation column. His assembler colleagues can't complain about that. They are complaining about clean compiles and debugging strange program behavior because the label is in the wrong column. How many times did I repeat the bug and he still says I'm complaining about the archaic fixed format (Even with source demonstrating the problem). Jons On Sunday, March 10, 2019, 1:47:02 PM PDT, Paul Gilmartin <0014e0e4a59b-dmarc- >On 2019-03-10, at 04:50:11, Tony Thigpen wrote: >> >> If you are fussing about the fixed-format of the input, > That's painfully archaic.
Re: Best practice using Conditional Assembly
On 2019-03-10 18:27, Jon Perryman wrote: In this case, it's not archaic. Column 16 is the standard assembler continuation column. His assembler colleagues can't complain about that. They are complaining about clean compiles and debugging strange program behavior because the label is in the wrong column. How many times did I repeat the bug and he still says I'm complaining about the archaic fixed format (Even with source demonstrating the problem). Jons On Sunday, March 10, 2019, 1:47:02 PM PDT, Paul Gilmartin <0014e0e4a59b-dmarc- >On 2019-03-10, at 04:50:11, Tony Thigpen wrote: If you are fussing about the fixed-format of the input, That's painfully archaic. Jon and Tony, could you please take this fight private. This is getting old. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/
Re: Best practice using Conditional Assembly
Jon, The problem is that you are assuming that my programmers are complaining about what happens when they use the macro contrary to the documentation. They don't. You are trying to argue an issue based on a false premise. My people are smart enough to read any abend dump and figure out that they did something stupid. Maybe your people are not and so you have to coddle them. It all boils down to you only wanting things to work the way you want them to, and not the way someone else wants them to. Is it the best code example? No. Does it work every time the coder uses it correctly? Yes. If the coder uses it incorrectly, does it affect the end user? No, if fails the first test run. And, yes, I did assemble it. I did not run it because, by design, it would abend if used incorrectly. Your just being picky. I'm done with the conversation. Tony Thigpen Jon Perryman wrote on 3/10/19 6:27 PM: In this case, it's not archaic. Column 16 is the standard assembler continuation column. His assembler colleagues can't complain about that. They are complaining about clean compiles and debugging strange program behavior because the label is in the wrong column. How many times did I repeat the bug and he still says I'm complaining about the archaic fixed format (Even with source demonstrating the problem). Jons On Sunday, March 10, 2019, 1:47:02 PM PDT, Paul Gilmartin <0014e0e4a59b-dmarc- >On 2019-03-10, at 04:50:11, Tony Thigpen wrote: If you are fussing about the fixed-format of the input, That's painfully archaic.
