Best practice using Conditional Assembly
Hi,.I construct a table using a set of Macros. The macro supports four different TYPE fuctions. I can have a TYPE=INITIAL, TYPE=ENTRY, TYPE=FINAL, and TYPE=DSECT. . TYPE=INITIAL basically sets up pointers to the first entry, last entry, and a count of the number of entries. . TYPE=ENTRY describes the individual elements in the table, each ENTRY is identified by a four character Transaction Code. . I want to know how best to identify a duplicate Transaction Code during Assembly of the Table. . For Example SV5000XX TYPE=INITIAL SV5000XX TYPE=ENTRY,XCODE=ABCD,P1=JOB001,P=JOB002,P3=JOB003 SV5000XX TYPE=ENTRY,XCODE=IJKL,P1=JOB021,P=JOB032,P3=JOB043 SV5000XX TYPE=ENTRY,XCODE=ABCD,P1=JOB0AA,P=JOB0BB,P3=JOB0CC SV5000XX TYPE=FINAL . In the above scenario, I would want to flag entry three as a duplicate XCODE of ABCD during assembly. . I want to know how best to identify a duplicate Transaction Code during Assembly of the Table. . Any suggestions - sample conditional assembly code would be best . Paul D'Angelo * * *
Re: Best practice using Conditional Assembly
Hi Paul, Others will give you code Define an LCLC array Keep a count of entries Before inserting a new entry, scan the array to see if &XCODE is already there If it is...it's a duplicate If not, add it and increment the count Melvyn Maltz - Original Message - From: "esst...@juno.com" To: Sent: Sunday, March 03, 2019 10:26 PM Subject: Best practice using Conditional Assembly Hi,.I construct a table using a set of Macros. The macro supports four different TYPE fuctions. I can have a TYPE=INITIAL, TYPE=ENTRY, TYPE=FINAL, and TYPE=DSECT. . TYPE=INITIAL basically sets up pointers to the first entry, last entry, and a count of the number of entries. . TYPE=ENTRY describes the individual elements in the table, each ENTRY is identified by a four character Transaction Code. . I want to know how best to identify a duplicate Transaction Code during Assembly of the Table. . For Example SV5000XX TYPE=INITIAL SV5000XX TYPE=ENTRY,XCODE=ABCD,P1=JOB001,P=JOB002,P3=JOB003 SV5000XX TYPE=ENTRY,XCODE=IJKL,P1=JOB021,P=JOB032,P3=JOB043 SV5000XX TYPE=ENTRY,XCODE=ABCD,P1=JOB0AA,P=JOB0BB,P3=JOB0CC SV5000XX TYPE=FINAL . In the above scenario, I would want to flag entry three as a duplicate XCODE of ABCD during assembly. . I want to know how best to identify a duplicate Transaction Code during Assembly of the Table. . Any suggestions - sample conditional assembly code would be best . Paul D'Angelo * * *
Re: Best practice using Conditional Assembly
Not incredibly elegant but I don't know how to do any better. You can't do in conditional assembler what you could do in Rexx, right? In Rexx, given "input" of ABCD you could set ABCD.IsDefined to TRUE and subsequently check it. You can't do that in conditional assembler, can you? Given an input parameter of ABCD, essentially define a LCLB named &XCODE? All conditional symbol names have to be hard-coded in the source code, right? Here's a real easy solution. You may or may not think it elegant. Have the macro generate &XCODE._Check EQU * that is, for example give XCODE=ABCD ABCD_Check EQU * and if it assembles in error, ABCD is a duplicate. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of MELVYN MALTZ Sent: Sunday, March 3, 2019 3:43 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best practice using Conditional Assembly Hi Paul, Others will give you code Define an LCLC array Keep a count of entries Before inserting a new entry, scan the array to see if &XCODE is already there If it is...it's a duplicate If not, add it and increment the count
Re: Best practice using Conditional Assembly
I'm sorry:Given an input parameter of ABCD, essentially define a LCLB named &ABCD?CharlesSent from a mobile; please excuse the brevity. Original message From: Charles Mills Date: 3/3/19 4:15 PM (GMT-08:00) To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best practice using Conditional Assembly Not incredibly elegant but I don't know how to do any better.You can't do in conditional assembler what you could do in Rexx, right? InRexx, given "input" of ABCD you could set ABCD.IsDefined to TRUE andsubsequently check it. You can't do that in conditional assembler, can you?Given an input parameter of ABCD, essentially define a LCLB named &XCODE?All conditional symbol names have to be hard-coded in the source code,right?Here's a real easy solution. You may or may not think it elegant. Have themacro generate&XCODE._Check EQU *that is, for example give XCODE=ABCDABCD_Check EQU *and if it assembles in error, ABCD is a duplicate.Charles-Original Message-From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]On Behalf Of MELVYN MALTZSent: Sunday, March 3, 2019 3:43 PMTo: assembler-l...@listserv.uga.EDUSubject: Re: Best practice using Conditional AssemblyHi Paul,Others will give you codeDefine an LCLC arrayKeep a count of entriesBefore inserting a new entry, scan the array to see if &XCODE is already thereIf it is...it's a duplicateIf not, add it and increment the count
Re: Best practice using Conditional Assembly
And if you want to generate your own error - instead of the assembler error, use the DEFINED attribute (i.e., D'&XCODE._Check) to test for ABCD being previously defined. Bill Hitefield Dino-Software Corporation 800.480.DINO 423.878.5660 www.dino-software.com -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Sunday, March 03, 2019 7:16 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best practice using Conditional Assembly Not incredibly elegant but I don't know how to do any better. You can't do in conditional assembler what you could do in Rexx, right? In Rexx, given "input" of ABCD you could set ABCD.IsDefined to TRUE and subsequently check it. You can't do that in conditional assembler, can you? Given an input parameter of ABCD, essentially define a LCLB named &XCODE? All conditional symbol names have to be hard-coded in the source code, right? Here's a real easy solution. You may or may not think it elegant. Have the macro generate &XCODE._Check EQU * that is, for example give XCODE=ABCD ABCD_Check EQU * and if it assembles in error, ABCD is a duplicate. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of MELVYN MALTZ Sent: Sunday, March 3, 2019 3:43 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best practice using Conditional Assembly Hi Paul, Others will give you code Define an LCLC array Keep a count of entries Before inserting a new entry, scan the array to see if &XCODE is already there If it is...it's a duplicate If not, add it and increment the count
Re: Best practice using Conditional Assembly
To me the easiest method is with global variables using a prefix to avoid variable name collisions. It's been a long time, so you may not be correct but you can understand the idea. gblb &(prefix&xcode) defaults to 0 first time aif (&(prefix&xcode)).error already definedprefix&xcode setb 1 I think (not sure) that LCL variables are dropped when the macro terminates. This wouldn't help your situation. Regards, Jon. On Sunday, March 3, 2019, 2:28:22 PM PST, esst...@juno.com wrote: Hi,.I construct a table using a set of Macros. The macro supports four different TYPE fuctions. I can have a TYPE=INITIAL, TYPE=ENTRY, TYPE=FINAL, and TYPE=DSECT. . TYPE=INITIAL basically sets up pointers to the first entry, last entry, and a count of the number of entries. . TYPE=ENTRY describes the individual elements in the table, each ENTRY is identified by a four character Transaction Code. . I want to know how best to identify a duplicate Transaction Code during Assembly of the Table. . For Example SV5000XX TYPE=INITIAL SV5000XX TYPE=ENTRY,XCODE=ABCD,P1=JOB001,P=JOB002,P3=JOB003 SV5000XX TYPE=ENTRY,XCODE=IJKL,P1=JOB021,P=JOB032,P3=JOB043 SV5000XX TYPE=ENTRY,XCODE=ABCD,P1=JOB0AA,P=JOB0BB,P3=JOB0CC SV5000XX TYPE=FINAL . In the above scenario, I would want to flag entry three as a duplicate XCODE of ABCD during assembly. . I want to know how best to identify a duplicate Transaction Code during Assembly of the Table. . Any suggestions - sample conditional assembly code would be best . Paul D'Angelo * * *
Re: Best practice using Conditional Assembly
If your TYPE=ENTRY macro invocations accumulate their parameter data in a global SETC array then it would be trivial to check for duplicates when adding entries. The TYPE=FINAL macro invocation would then generate the table in addition to to doing whatever it currently does. Regards,Keven On Sun, Mar 3, 2019 at 8:15 PM -0600, "Jon Perryman" wrote: To me the easiest method is with global variables using a prefix to avoid variable name collisions. It's been a long time, so you may not be correct but you can understand the idea. gblb &(prefix&xcode) defaults to 0 first time aif (&(prefix&xcode)).error already definedprefix&xcode setb 1 I think (not sure) that LCL variables are dropped when the macro terminates. This wouldn't help your situation. Regards, Jon. On Sunday, March 3, 2019, 2:28:22 PM PST, esst...@juno.com wrote: Hi,.I construct a table using a set of Macros. The macro supports four different TYPE fuctions. I can have a TYPE=INITIAL, TYPE=ENTRY, TYPE=FINAL, and TYPE=DSECT. . TYPE=INITIAL basically sets up pointers to the first entry, last entry, and a count of the number of entries. . TYPE=ENTRY describes the individual elements in the table, each ENTRY is identified by a four character Transaction Code. . I want to know how best to identify a duplicate Transaction Code during Assembly of the Table. . For Example SV5000XX TYPE=INITIAL SV5000XX TYPE=ENTRY,XCODE=ABCD,P1=JOB001,P=JOB002,P3=JOB003 SV5000XX TYPE=ENTRY,XCODE=IJKL,P1=JOB021,P=JOB032,P3=JOB043 SV5000XX TYPE=ENTRY,XCODE=ABCD,P1=JOB0AA,P=JOB0BB,P3=JOB0CC SV5000XX TYPE=FINAL . In the above scenario, I would want to flag entry three as a duplicate XCODE of ABCD during assembly. . I want to know how best to identify a duplicate Transaction Code during Assembly of the Table. . Any suggestions - sample conditional assembly code would be best . Paul D'Angelo * * *
Re: Best practice using Conditional Assembly
On Sun, 3 Mar 2019 at 19:15, Charles Mills wrote: > You can't do in conditional assembler what you could do in Rexx, right? In > Rexx, given "input" of ABCD you could set ABCD.IsDefined to TRUE and > subsequently check it. You can't do that in conditional assembler, can you? > Given an input parameter of ABCD, essentially define a LCLB named &XCODE? You *can* do something similar in conditional assembler. They're called created SET symbols, and the syntax is roughly &(&xxx) SETB 1 where &xxx can be an expression just as well as a single variable symbol. They can appear anywhere an ordinary SET symbol can, e.g. in GBLx, SETx, and all the various references. One big difference from REXX is that the resulting created symbols have to be syntactically valid, i.e.start with an "&", then an alpha (including $, #, @, _), and contain only the usual alphanumerics in the rest. > All conditional symbol names have to be hard-coded in the source code, right? No. Tony H.
Re: Best practice using Conditional Assembly
Cool! New since I was last writing serious HLASM macros. Also suggested by someone else. It's a good solution to the stated problem but I think the GBLC array might be his best solution overall since it would feed directly into generating the table. It's not elegant -- sequentially searching an unsorted character array again and again in what is basically an interpreted language -- but it would do the job. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tony Harminc Sent: Monday, March 4, 2019 9:53 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best practice using Conditional Assembly On Sun, 3 Mar 2019 at 19:15, Charles Mills wrote: > You can't do in conditional assembler what you could do in Rexx, right? In > Rexx, given "input" of ABCD you could set ABCD.IsDefined to TRUE and > subsequently check it. You can't do that in conditional assembler, can you? > Given an input parameter of ABCD, essentially define a LCLB named &XCODE? You *can* do something similar in conditional assembler. They're called created SET symbols, and the syntax is roughly &(&xxx) SETB 1 where &xxx can be an expression just as well as a single variable symbol. They can appear anywhere an ordinary SET symbol can, e.g. in GBLx, SETx, and all the various references. One big difference from REXX is that the resulting created symbols have to be syntactically valid, i.e.start with an "&", then an alpha (including $, #, @, _), and contain only the usual alphanumerics in the rest.
Re: Best practice using Conditional Assembly
To eliminate performing an array lookup to locate the entry for the needed value, you could use an LCLA SET symbol to represent the array key. This allows the assembler to keep track of the subscripts for you. For example: MACRO &VALUE= ... GBLA&(INDEX_&VALUE), &GBLA_CTR1 ... &GBLA_CTR1 SETA &GBLA_CTR1+1 &(INDEX_VALUE) SETA &GBLA_CTR1 ... Later on in the final macro, you could reference the array entries for value 'ABCD' by the following: &INDEX SETA&(INDEX_ABCD) ... &VALUE1 SETC &ARRAY1(&INDEX) ... and so on Bill Hitefield Dino-Software Corporation 800.480.DINO 423.878.5660 www.dino-software.com -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Monday, March 04, 2019 2:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best practice using Conditional Assembly Cool! New since I was last writing serious HLASM macros. Also suggested by someone else. It's a good solution to the stated problem but I think the GBLC array might be his best solution overall since it would feed directly into generating the table. It's not elegant -- sequentially searching an unsorted character array again and again in what is basically an interpreted language -- but it would do the job. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tony Harminc Sent: Monday, March 4, 2019 9:53 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best practice using Conditional Assembly On Sun, 3 Mar 2019 at 19:15, Charles Mills wrote: > You can't do in conditional assembler what you could do in Rexx, > right? In Rexx, given "input" of ABCD you could set ABCD.IsDefined to > TRUE and subsequently check it. You can't do that in conditional assembler, > can you? > Given an input parameter of ABCD, essentially define a LCLB named &XCODE? You *can* do something similar in conditional assembler. They're called created SET symbols, and the syntax is roughly &(&xxx) SETB 1 where &xxx can be an expression just as well as a single variable symbol. They can appear anywhere an ordinary SET symbol can, e.g. in GBLx, SETx, and all the various references. One big difference from REXX is that the resulting created symbols have to be syntactically valid, i.e.start with an "&", then an alpha (including $, #, @, _), and contain only the usual alphanumerics in the rest.
Re: Best practice using Conditional Assembly
Using GBLC is rarely needed to generate these types of tables (e.g. cics and IMS definitions). If you really need the table in a different location, then use LOCTR. Even generating a different CSECT would work. Regards, Jon. On Monday, March 4, 2019, 11:27:15 AM PST, Charles Mills wrote: Cool! New since I was last writing serious HLASM macros. Also suggested by someone else. It's a good solution to the stated problem but I think the GBLC array might be his best solution overall since it would feed directly into generating the table. It's not elegant -- sequentially searching an unsorted character array again and again in what is basically an interpreted language -- but it would do the job. Charles
Re: Best practice using Conditional Assembly
The OP’s table is built with multiple macro invocations so a global SETC variable is required in order for the table to persist from one invocation to the next. Keven On Mon, Mar 4, 2019 at 7:51 PM -0600, "Jon Perryman" wrote: Using GBLC is rarely needed to generate these types of tables (e.g. cics and IMS definitions). If you really need the table in a different location, then use LOCTR. Even generating a different CSECT would work. Regards, Jon. On Monday, March 4, 2019, 11:27:15 AM PST, Charles Mills wrote: Cool! New since I was last writing serious HLASM macros. Also suggested by someone else. It's a good solution to the stated problem but I think the GBLC array might be his best solution overall since it would feed directly into generating the table. It's not elegant -- sequentially searching an unsorted character array again and again in what is basically an interpreted language -- but it would do the job. Charles
Re: Best practice using Conditional Assembly
The OP may want to change to an AREAD loop within one macro. I have
attached one of my simpler ones. It generates a branch table with range
checking. I have more complex ones that build tables just like the OP
wants. The attached macro us used thus:
BRANCH_ON (R15)
SSS_CK_ENTRIES 0
SSS_CK_TOO_MANY 4
SSS_CK_NONE 8
SSS_CK_BADR15 12
SSS_CK_BADR15 16
-
SSS_CK_BADR15 DS 0H
MESSAGE 0026,=CL8'CHECK',RETCODE
B RETURN16
Here is an example of the data input to one of my complex macros build a
data table:
PTABLE PREFIX=PK_,LENGTH_ID=KT_E_LENGTH
DUMMYCHAR
COMPANY_NAME CHAR
PASSWORD CHAR
SUPPORT_EMAIL_ADDR CHAR
FF XXX
The program using this macro actually builds about 200 table rows, not
just the 4 I am showing.
Tony Thigpen
Keven wrote on 3/4/19 11:47 PM:
The OP’s table is built with multiple macro invocations so a global SETC variable is required in order for the table to persist from one invocation to the next.
Keven
On Mon, Mar 4, 2019 at 7:51 PM -0600, "Jon Perryman"
wrote:
Using GBLC is rarely needed to generate these types of tables (e.g. cics and
IMS definitions).
If you really need the table in a different location, then use LOCTR. Even
generating a different CSECT would work.
Regards, Jon.
On Monday, March 4, 2019, 11:27:15 AM PST, Charles Mills wrote:
Cool! New since I was last writing serious HLASM macros. Also suggested by someone else. It's a good solution to the stated problem but I think the GBLC array might be his best solution overall since it would feed directly into generating the table. It's not elegant -- sequentially searching an unsorted character array again and again in what is basically an interpreted language -- but it would do the job.
Charles
MACRO
&NAMEBRANCH_ON &ADDR,&BAD_VALUE= ~
&GOBAD SETC 'A&SYSNDX'
AIF ('&BAD_VALUE' EQ '' ).NOBV
&GOBAD SETC '&BAD_VALUE'
.NOBVANOP
MACPARM L,R1,&ADDR
CLR1,A&SYSNDX MUST BE LOGICAL, NOT NBR COMPARE
BH&GOBAD . BRANCHES FOR BOTH HIGH & MINUS
LAR0,3
NRR0,R1
*LTR R0,R0 REMOVED 8/25/12 AS NR SETS THE CC
BNZ &GOBAD
B B&SYSNDX.(R1)
B&SYSNDX DS0F
.READANOP
&CARDAREAD NOSTMT
&FLD SETC '&CARD'(16,39)
&COMMENT SETC '&CARD'(40,30)
AIF ('&CARD'(1,1) EQ '*').READ
AIF ('&CARD'(16,1) EQ '-').CARDEND
AIF ('&CARD'(16,1) EQ ' ').INVALID
AIF ('&CARD'(16,3) EQ 'N/A').INVALID
.GETLANOP
&L SETA 0
.GETFLD AIF ('&FLD'(&L+1,1) EQ ' ').STORE
&L SETA &L+1
AGO .GETFLD
.INVALID ANOP
&FLD SETC '&GOBAD '
AGO .GETL
.STORE ANOP
&WHERE SETC '&FLD'(1,&L)
&WHEREX SETC '&WHERE '(1,24)
B &WHEREX&COMMENT
AGO .READ
.CARDEND ANOP
DS0H
A&SYSNDX DCX''FORCE ABEND | MUST BE TOGETHER FOR THE
C&SYSNDX DCY(*-B&SYSNDX-4-2) | CL TEST TO WORK
MEND
Re: Best practice using Conditional Assembly
Never use AREAD unless it's really needed and you are willing to code it correctly. Circumventing the assembler is not helpful. AREAD bypasses assembler syntax, parsing and messages. It also requires a lot more code than programmers are willing to write and there are so many exceptions that get ignored. If you use the BRANCH_ON example, make sure you don't have a coding error. If your branch label started in column 17 instead of 16, you'll be reading a dump to find your mistake. If you code a label starting before column 16, then everything before column 16 is simply ignored. If starting in column 16 is also a valid label, then you must diagnose a bad branch to find this error. The correct assembler syntax for the branch table would be BR_TABLE=(labell00,label04,label08,...). The loop is a simple &BR_TABLE(&CNT) until &CNT > N'&BR_TABLE. For PTABLE, the correct assembler syntax would be TABLE=((xxx,CHAR),(xxx,CHAR),...). Regards, Jon. On Thursday, March 7, 2019, 1:37:10 PM PST, Tony Thigpen wrote: The OP may want to change to an AREAD loop within one macro. I have attached one of my simpler ones. It generates a branch table with range checking. I have more complex ones that build tables just like the OP wants. The attached macro us used thus: BRANCH_ON (R15) SSS_CK_ENTRIES 0 SSS_CK_TOO_MANY 4 SSS_CK_NONE 8 SSS_CK_BADR15 12 SSS_CK_BADR15 16 - SSS_CK_BADR15 DS 0H MESSAGE 0026,=CL8'CHECK',RETCODE B RETURN16 Here is an example of the data input to one of my complex macros build a data table: PTABLE PREFIX=PK_,LENGTH_ID=KT_E_LENGTH DUMMY CHAR COMPANY_NAME CHAR PASSWORD CHAR SUPPORT_EMAIL_ADDR CHAR FF XXX The program using this macro actually builds about 200 table rows, not just the 4 I am showing. Tony Thigpen Keven wrote on 3/4/19 11:47 PM: > > The OP’s table is built with multiple macro invocations so a global >SETC variable is required in order for the table to persist from one >invocation to the next. > Keven
Re: Best practice using Conditional Assembly
So, your statement comes down to "Don't use AREAD because it's not HLASM." 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. I said this was a simple version. Some of my more complex ones use INDEX and such to make it more error proof. I just posted a simple example so the OP could have something to show what I was talking about. Tony Thigpen Jon Perryman wrote on 3/7/19 11:54 PM: Never use AREAD unless it's really needed and you are willing to code it correctly. Circumventing the assembler is not helpful. AREAD bypasses assembler syntax, parsing and messages. It also requires a lot more code than programmers are willing to write and there are so many exceptions that get ignored. If you use the BRANCH_ON example, make sure you don't have a coding error. If your branch label started in column 17 instead of 16, you'll be reading a dump to find your mistake. If you code a label starting before column 16, then everything before column 16 is simply ignored. If starting in column 16 is also a valid label, then you must diagnose a bad branch to find this error. The correct assembler syntax for the branch table would be BR_TABLE=(labell00,label04,label08,...). The loop is a simple &BR_TABLE(&CNT) until &CNT > N'&BR_TABLE. For PTABLE, the correct assembler syntax would be TABLE=((xxx,CHAR),(xxx,CHAR),...). Regards, Jon. On Thursday, March 7, 2019, 1:37:10 PM PST, Tony Thigpen wrote: The OP may want to change to an AREAD loop within one macro. I have attached one of my simpler ones. It generates a branch table with range checking. I have more complex ones that build tables just like the OP wants. The attached macro us used thus: BRANCH_ON (R15) SSS_CK_ENTRIES 0 SSS_CK_TOO_MANY 4 SSS_CK_NONE 8 SSS_CK_BADR15 12 SSS_CK_BADR15 16 - SSS_CK_BADR15 DS 0H MESSAGE 0026,=CL8'CHECK',RETCODE B RETURN16 Here is an example of the data input to one of my complex macros build a data table: PTABLE PREFIX=PK_,LENGTH_ID=KT_E_LENGTH DUMMY CHAR COMPANY_NAME CHAR PASSWORD CHAR SUPPORT_EMAIL_ADDR CHAR FF XXX The program using this macro actually builds about 200 table rows, not just the 4 I am showing. Tony Thigpen Keven wrote on 3/4/19 11:47 PM: The OP’s table is built with multiple macro invocations so a global SETC variable is required in order for the table to persist from one invocation to the next. Keven
Re: Best practice using Conditional Assembly
Pardon me for jumping in- >> considering that the one that told me to use AREAD, IMNSHO the question is as important as the answer! Martin
Re: Best practice using Conditional Assembly
I wish I still had those emails. John was very helpful to me back around Y2K with suggestions on how to use the advanced features of HLASM to make my life easier. *ALL* my knowledge of writing macros comes from his tutelage and reading his three 'how to' guides. Tony Thigpen Martin Truebner wrote on 3/8/19 5:07 AM: Pardon me for jumping in- considering that the one that told me to use AREAD, IMNSHO the question is as important as the answer! Martin
Re: Best practice using Conditional Assembly
On 3/7/2019 8:54 PM, Jon Perryman wrote: Never use AREAD unless it's really needed and you are willing to code it correctly. Circumventing the assembler is not helpful. AREAD/AINSERT is arguably the most powerful single mechanism in all of HLASM. We use it *everywhere* to build tables and we've even created a sort of "compiler" that allows us to do wondrous things. I highly recommend its use! -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Best practice using Conditional Assembly
I think Jon Perryman's comment deserves a little more respect. Another famous guy, Albert Einstein, famously said something like keep things as simple as possible. There's a bad tendency among some to play with any shiny new tool they find, regardless of whether it's actually appropriate for the task at hand. Nevertheless, the next part of the famous quote was "but no simpler." AREAD is a useful tool, and is great when it makes something difficult easier. Jon P. allowed for that in his post, too. sas On Fri, Mar 8, 2019 at 9:35 AM Ed Jaffe wrote: > On 3/7/2019 8:54 PM, Jon Perryman wrote: > > Never use AREAD unless it's really needed and you are willing to code it > correctly. Circumventing the assembler is not helpful. > > AREAD/AINSERT is arguably the most powerful single mechanism in all of > HLASM. We use it *everywhere* to build tables and we've even created a > sort of "compiler" that allows us to do wondrous things. I highly > recommend its use! > > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/
Re: Best practice using Conditional Assembly
Ed, That sounds like a great topic for a SHARE presentation on advanced assembler usage, if it's not considered too proprietary to release into the wild. Any chance of that happening? Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ed Jaffe Sent: Friday, March 8, 2019 10:35 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best practice using Conditional Assembly On 3/7/2019 8:54 PM, Jon Perryman wrote: > Never use AREAD unless it's really needed and you are willing to code it > correctly. Circumventing the assembler is not helpful. AREAD/AINSERT is arguably the most powerful single mechanism in all of HLASM. We use it *everywhere* to build tables and we've even created a sort of "compiler" that allows us to do wondrous things. I highly recommend its use! -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: Best practice using Conditional Assembly
I'd be okay with that. I'll put together an abstract... On 3/8/2019 8:01 AM, Farley, Peter x23353 wrote: Ed, That sounds like a great topic for a SHARE presentation on advanced assembler usage, if it's not considered too proprietary to release into the wild. Any chance of that happening? Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ed Jaffe Sent: Friday, March 8, 2019 10:35 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best practice using Conditional Assembly On 3/7/2019 8:54 PM, Jon Perryman wrote: Never use AREAD unless it's really needed and you are willing to code it correctly. Circumventing the assembler is not helpful. AREAD/AINSERT is arguably the most powerful single mechanism in all of HLASM. We use it *everywhere* to build tables and we've even created a sort of "compiler" that allows us to do wondrous things. I highly recommend its use! This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Best practice using Conditional Assembly
Ref: Your note of Fri, 8 Mar 2019 16:01:45 + I've used AREAD a lot (for example for in-line message tables and as a simple way to enable or disable debugging code) and AINSERT too, especially for some tricks relating to global variables which couldn't be done any other way. I feel that it is important to minimize the number of different languages involved in an assembly, so if Assembler syntax can do the job conveniently, then that should be used instead of inventing a new syntax processed with AREAD. However, if some other syntax is more convenient (for example to imbed tables or documentation) then AREAD can be very useful. Note also that data to be processed with AREAD can trigger nasty problems with lookahead if it resembles valid Assembler statements. (I similarly feel that although structured programming macros are very useful, I normally only use IF with a condition, not with included instructions, simply in order that the instruction does not have to be coded using a different syntax). When AINSERT was invented, about 20 years ago, the HLASM team failed to anticipate some of the ingenious ways in which it might be used, especially inserting COPY statements and code containing sequence symbols, which caused all sorts of problems. So many things which looked as if they should work caused unpredictable results. Last year we shipped major internal changes to HLASM lookahead support (APAR PI90075) which we hope will fix those problems, especially relating to supporting sequence symbols. We had to make some small changes to the language rules to ensure consistency, but as far as we know the only cases likely to be affected would not have worked (at least not reliably) anyway. So I hope we can now say that if you want to use AREAD/AINSERT techniques to process input, it should all work fine, but be aware of the limitations. In particular, the fact that these work back at the open code level can cause nasty surprises if people try to use macros that rely on AREAD/AINSERT inside other macros. Jonathan Scott HLASM, IBM Hursley, UK
Re: Best practice using Conditional Assembly
Useful, yes. Most powerful - not even close. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Ed Jaffe Sent: Friday, March 8, 2019 10:35 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best practice using Conditional Assembly On 3/7/2019 8:54 PM, Jon Perryman wrote: > Never use AREAD unless it's really needed and you are willing to code it > correctly. Circumventing the assembler is not helpful. AREAD/AINSERT is arguably the most powerful single mechanism in all of HLASM. We use it *everywhere* to build tables and we've even created a sort of "compiler" that allows us to do wondrous things. I highly recommend its use! -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1ko0GcbniJUU5QFvzmlMsuSzNYnKNEwEib5ANQ9IHxB7ysQd4MFqNotJ7FpFtIv3FuTHAPq_-b0ODHK6A9cSI3Y5EcRexpbX8oP_SiJpVqXQ59fGz5kseYtbErEaQpWBbr03Cjc40IuF_zVTHe_UsqeRfkgqlsHWeWMwaPo0YvBK_rg0mGkvVVtdkGKT8y3mUdKofFEl0J82osAdVI5Ccp0S8xz_Cyj-kO53Vk98HVHublziEFHA532pYoAMtNVFbgCHMApJWL8Cvk7Y86SFv8gRu0d0Cte--B1IrbOzDSb-OB81hAoI35y53CoI5ZffMJmlJq0dIeVBUzizBeps6SSLu0aMMzbceS2RYGR2Sz3Joivmp8rWagEfRjsxL5gV5PSdOXmIDVFl9o5wAUwztMyRMpp4Q2d2rmOaOBOaWheJ5bwqypgJL0KahN0_fJKW6/https%3A%2F%2Fwww.phoenixsoftware.com%2F This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Best practice using Conditional Assembly
IMHO we all owe a large debt of gratitude to John and Greg. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Tony Thigpen Sent: Friday, March 8, 2019 5:22 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best practice using Conditional Assembly I wish I still had those emails. John was very helpful to me back around Y2K with suggestions on how to use the advanced features of HLASM to make my life easier. *ALL* my knowledge of writing macros comes from his tutelage and reading his three 'how to' guides. Tony Thigpen Martin Truebner wrote on 3/8/19 5:07 AM: > Pardon me for jumping in- > >>> considering that the one that told me to use AREAD, > > IMNSHO the question is as important as the answer! > > Martin > >
Re: Best practice using Conditional Assembly
Never use any facility unless it is really needed and you are willing to code it correctly. AREAD has legitimate uses, and since it is prt of HLASM then using it is not circumventing the assembler. "When the only tool you have is a pipe, everything looks like a filter." -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Jon Perryman Sent: Thursday, March 7, 2019 11:54 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best practice using Conditional Assembly Never use AREAD unless it's really needed and you are willing to code it correctly. Circumventing the assembler is not helpful. AREAD bypasses assembler syntax, parsing and messages. It also requires a lot more code than programmers are willing to write and there are so many exceptions that get ignored. If you use the BRANCH_ON example, make sure you don't have a coding error. If your branch label started in column 17 instead of 16, you'll be reading a dump to find your mistake. If you code a label starting before column 16, then everything before column 16 is simply ignored. If starting in column 16 is also a valid label, then you must diagnose a bad branch to find this error. The correct assembler syntax for the branch table would be BR_TABLE=(labell00,label04,label08,...). The loop is a simple &BR_TABLE(&CNT) until &CNT > N'&BR_TABLE. For PTABLE, the correct assembler syntax would be TABLE=((xxx,CHAR),(xxx,CHAR),...). Regards, Jon. On Thursday, March 7, 2019, 1:37:10 PM PST, Tony Thigpen wrote: The OP may want to change to an AREAD loop within one macro. I have attached one of my simpler ones. It generates a branch table with range checking. I have more complex ones that build tables just like the OP wants. The attached macro us used thus: BRANCH_ON (R15) SSS_CK_ENTRIES 0 SSS_CK_TOO_MANY4 SSS_CK_NONE8 SSS_CK_BADR15 12 SSS_CK_BADR15 16 - SSS_CK_BADR15 DS 0H MESSAGE 0026,=CL8'CHECK',RETCODE BRETURN16 Here is an example of the data input to one of my complex macros build a data table: PTABLE PREFIX=PK_,LENGTH_ID=KT_E_LENGTH DUMMYCHAR COMPANY_NAMECHAR PASSWORDCHAR SUPPORT_EMAIL_ADDR CHAR FF XXX The program using this macro actually builds about 200 table rows, not just the 4 I am showing. Tony Thigpen Keven wrote on 3/4/19 11:47 PM: > > The OP’s table is built with multiple macro invocations so a global >SETC variable is required in order for the table to persist from one >invocation to the next. > Keven
Re: Best practice using Conditional Assembly
On 2019-03-08, at 10:06:12, Jonathan Scott wrote: > > When AINSERT was invented, about 20 years ago, the HLASM team > failed to anticipate some of the ingenious ways in which it > might be used, especially inserting COPY statements ... > The need to AINSERT COPY statements is a relic of a painfully resource-constrained predecessor which required that AIF and COPY be performed in separate passes. Designers faced the difficult choice of which to do first. They chose to do COPY first, prohibiting the obvious use of AIF to bypass copy in order to support AIF in copybook members. A better design would provide a conditional COPY. -- gil
Re: Best practice using Conditional Assembly
RFE? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, March 8, 2019 2:37 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best practice using Conditional Assembly On 2019-03-08, at 10:06:12, Jonathan Scott wrote: > > When AINSERT was invented, about 20 years ago, the HLASM team > failed to anticipate some of the ingenious ways in which it > might be used, especially inserting COPY statements ... > The need to AINSERT COPY statements is a relic of a painfully resource-constrained predecessor which required that AIF and COPY be performed in separate passes. Designers faced the difficult choice of which to do first. They chose to do COPY first, prohibiting the obvious use of AIF to bypass copy in order to support AIF in copybook members. A better design would provide a conditional COPY. -- gil
Re: Best practice using Conditional Assembly
Years ago I suggested the need for an ACOPY statement that would only be processed if conditional assembly did not bypass it. But I never created a Share requirement or RFE. Keith Sent from an iPhone > On Mar 8, 2019, at 12:37, Paul Gilmartin > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > >> On 2019-03-08, at 10:06:12, Jonathan Scott wrote: >> >> When AINSERT was invented, about 20 years ago, the HLASM team >> failed to anticipate some of the ingenious ways in which it >> might be used, especially inserting COPY statements ... >> > The need to AINSERT COPY statements is a relic of a painfully > resource-constrained predecessor which required that AIF and > COPY be performed in separate passes. Designers faced the > difficult choice of which to do first. They chose to do COPY > first, prohibiting the obvious use of AIF to bypass copy in > order to support AIF in copybook members. A better design > would provide a conditional COPY. > > -- gil
Re: Best practice using Conditional Assembly
Sorry Tony, I was trying (apparently unsuccessfully) not to be insulting. You recommended to the op that he should consider AREAD. With less than 5% of macro's being improved by AREAD, what did you notice that AREAD needed to be a consideration? I'm all for using AREAD when it's needed but it's used too often when there are better assembler implementations. 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. Why show an incorrectly coded AREAD macro instead of using a correctly coded AREAD macro? Do you believe John Erlich would have recommended using AREAD to build a simple branch table in this way? Do you believe he would have approved of your implementation AREAD in BRANCH_ON? I'm sure you could code it correctly but my point is that AREAD is not trivial where as there are trivial assembler solutions in many cases. If you are going to use advocate the use of AREAD, then it needs to be used correctly and when it's truly beneficial. Regards, Jon. On Friday, March 8, 2019, 2:00:50 AM PST, Tony Thigpen wrote: So, your statement comes down to "Don't use AREAD because it's not HLASM." 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. I said this was a simple version. Some of my more complex ones use INDEX and such to make it more error proof. I just posted a simple example so the OP could have something to show what I was talking about.
Re: Best practice using Conditional Assembly
Hi Ed, You said you highly recommend using AREAD & AINSERT. With their limitations and restrictions, I'm surprised you could be so unequivocal. Can you show us an example of a second macro using one an AREAD based macro with the data in that macro? After looking at the BRANCH_ON macro, would you want someone unfamiliar wth AREAD to model their code after it? AREAD certainly gives you a lot of flexibility and I have used it but it should be used with caution. Regards, Jon. On Friday, March 8, 2019, 7:35:37 AM PST, Ed Jaffe wrote: On 3/7/2019 8:54 PM, Jon Perryman wrote: > Never use AREAD unless it's really needed and you are willing to code it > correctly. Circumventing the assembler is not helpful. AREAD/AINSERT is arguably the most powerful single mechanism in all of HLASM.
Re: Best practice using Conditional Assembly
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
wrote:
*PROCESS NORENT
*PROCESS FLAG(PAGE0)
PRINT OFF
MACRO
MTABLE &TYPE
ACTR 1
AIF ('&TYPE' EQ 'DSECT').DSECT
LCLA &C,&I,&J,&Z
LCLC &MSG(500),&TPY(500)
LCLC &V1(500),&L1(500),&V2(500),&L2(500)
LCLC &V3(500),&L3(500),&V4(500),&L4(500)
LCLC &CON(500),&LST(500),&TXT(500),&TAG
LCLA &L
LCLC &T,&M
.READANOP
&CARDAREAD NOSTMT
AIF ('&CARD'(1,5) EQ 'F').CARDEND
AIF ('&CARD'(1,1) EQ '*').READ
&C SETA &C+1
&MSG(&C) SETC '&CARD'(1,4)
&TYP(&C) SETC '&CARD'(5,1)
&CON(&C) SETC '&CARD'(6,1)
&LST(&C) SETC '&CARD'(7,1)
&V1(&C) SETC '&CARD'(8,1)
&L1(&C) SETC '&CARD'(9,2)
&V2(&C) SETC '&CARD'(11,1)
&L2(&C) SETC '&CARD'(12,2)
&V3(&C) SETC '&CARD'(14,1)
&L3(&C) SETC '&CARD'(15,2)
&V4(&C) SETC '&CARD'(17,1)
&L4(&C) SETC '&CARD'(18,2)
&Z SETA 73-(18+2+1) LENGTH OF TEXT IN INPUT CARD
&TXT(&C) SETC '&CARD'(18+2+1,&Z)
AGO .READ
.CARDEND ANOP
MESSAGE_TABLE DS 0D
.TABLE ANOP
&I SETA &I+1
AIF (&I GT &C).DOTEXT
AIF ('&MSG(&I)'(1,1) EQ '*').TABLE
&TAG SETC 'M_'.'&MSG(&I)'
DCH'&MSG(&I)',H'0'
DCCL1'&TYP(&I)',CL1'&CON(&I)',CL1'&LST(&I)',C' '
DCA(&TAG)
DCH'&L1(&I)',C'&V1(&I)',C' '
DCH'&L2(&I)',C'&V2(&I)',C' '
DCH'&L3(&I)',C'&V3(&I)',C' '
DCH'&L4(&I)',C'&V4(&I)',C' '
AGO .TABLE
.DOTEXT ANOP
DCX''
.TEXTANOP
&J SETA &J+1
AIF (&J GT &C).DONE
AIF ('&MSG(&J)'(1,1) EQ '*').TEXT
.* GET MESSAGE AND CALCULATE LENGTH
&M SETC '&TXT(&J)'
&M SETC '&M'(1,&Z)
&L SETA &Z
.TRIMAIF ('&M'(&L,1) NE ' ').DOUBLE
&L SETA &L-1
AGO .TRIM
.DOUBLE ANOP
&T SETC (DOUBLE '&M'(1,&L))
&TAG SETC 'M_'.'&MSG(&J)'
&TAG DCH'&L'
DCC'&T'
AGO .TEXT
.DONEMEXIT
.DSECT ANOP
MESSAGES DSECT DSECT FOR PARM AREA
M_NBRDSH MESSAGE NUMBER
DSH RESERVED
M_TYPE DSC MESSAGE TYPE
M_CONSOLE DS C MESSAGE LOCATION
M_SYSLST DSC MESSAGE LOCATION
DSC RESERVED
M_@TEXT DSA ADDRESS OF MESSAGE TEXT
M_L1 DSH RESULT LENGTH OF REPLACEMENT 1
M_M1 DSC METHOD OF REPLACEMENT 1
M_M_NONE EQU C' 'NO REPLACEMENT
M_M_CHAR EQU C'C'CHARACTER
M_M_PACK EQU C'P'PACK8
M_M_HEX EQU C'X'HEX (DISPLAY BASE 16)
M_M_BYTE EQU C'B' BYTE (DISPLAY BASE 10)
M_M_HALF EQU C'H' HALFWORD (DISPLAY BASE 10)
M_M_FULL EQU C'F' FULLWORD (DISPLAY BASE 10)
M_M_IP EQU C'I' 16 BYTE IP ADDRESS
DSC RESERVED
M_L2 DSH RESULT LENGTH OF REPLACEMENT 2
M_M2 DSC METHOD OF REPLACEMENT 2
DSC RESERVED
M_L3 DS
Re: Best practice using Conditional Assembly
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 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 > wrote: >
Re: Best practice using Conditional Assembly
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 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 wrote:
Re: Best practice using Conditional Assembly
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.
Re: Best practice using Conditional Assembly
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.
Re: Best practice using Conditional Assembly
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 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. > >
Re: Best practice using Conditional Assembly
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
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.
