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 <[email protected]>
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
FFFFFF 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
