Re: [PossibleSpam] Re: AREAD question
Right... but for the CL, you want F-word alignment anyway, although it would only cause a trivial warning if it wasn't. As for the "oh-so-clever" remark, it only meant reusing an adcon as the branch target... it's a very minor point; I'd just prefer something like B *+1 or EX Rx,* that more clearly doesn't look like an accident. OTOH, it's not as easy if you have no code-base. It is very true that anything is better than a wild branch. sas On Mon, May 3, 2021 at 8:00 PM Tony Thigpen wrote: > Thanks for the alignment issue. I went back and found that a DS 0H was > in the code in some historical copies of the macro, but not in all the > copies. I must have fat-fingered a line delete at some point. > > Also, the SOC1 is only if I did not tell the macro how to handle a bad > value. With some of my code, I am just too deep in the levels and past > all other edits. So, as such, there should "never" be a bad value. So, > instead of having to set up a new message or returning up the code > levels, I want an abend so I can actually review the dump and see what > happened. > > I know too many programmers that say "it will never happen" and so don't > put some sort of trap in "just in case". Eventually, they will get burnt. > > Many years ago, there was a piece of software that put out a message: > "Call Joe at x and tell him he owes Bob $10". Bob had bet Joe that > some condition could never occur, but it did. Bob got his $10. :-) > > Tony Thigpen > >
Re: [PossibleSpam] Re: AREAD question
I've done both single macros with lists and separae prolog/item/epilog macros and and haven't seen much of a difference. IMHO, either is preferable to AREAD. I tend to use LOCTR, immediate operands or literals rather than jumping around constants. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Steve Smith [sasd...@gmail.com] Sent: Tuesday, May 4, 2021 8:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: [PossibleSpam] Re: AREAD question Ah, OK. If I re-coded this, there would be separate macros for each entry. A final end-of-table macro would set an EQU to the length needed to generate the code. The macros could easily be the same macro source, with a type operand. But overall, I think it's simpler and clearer than to pile multiple entries into an operand list. Much easier to add/delete entries, too (which the AREAD version also has). sas On Tue, May 4, 2021 at 5:33 AM Seymour J Metz wrote: > The added parameter is in place of the AREAD. > >
Re: [PossibleSpam] Re: AREAD question
Ah, OK. If I re-coded this, there would be separate macros for each entry. A final end-of-table macro would set an EQU to the length needed to generate the code. The macros could easily be the same macro source, with a type operand. But overall, I think it's simpler and clearer than to pile multiple entries into an operand list. Much easier to add/delete entries, too (which the AREAD version also has). sas On Tue, May 4, 2021 at 5:33 AM Seymour J Metz wrote: > The added parameter is in place of the AREAD. > >
Re: [PossibleSpam] Re: AREAD question
The added parameter is in place of the AREAD. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Steve Smith [sasd...@gmail.com] Sent: Monday, May 3, 2021 6:32 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: [PossibleSpam] Re: AREAD question There's no need for more parameters... just maybe a GBLA. Frankly, I think branch tables are simple enough to code, including automatic range checking, as to not be worth macros at all. Whatever. btw, HLASM is pretty smart, but it doesn't read your commentary: A DCX''FORCE ABEND | MUST BE TOGETHER FOR THE C DCY(*-B) | CL TEST TO WORK TT 050610 You have an unaligned constant in front of an aligned one, and they have to be together. Lucky for you they are until someone tweaks your macro. A DCA(*-B) ..is what you want. That oh-so-clever S0C1 for an out-of-range value will work just as well. sas On Mon, May 3, 2021 at 5:36 PM Seymour J Metz wrote: > The same would be true if you used macro parameters. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Tony Thigpen [t...@vse2pdf.com] > Sent: Monday, May 3, 2021 5:24 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: [PossibleSpam] Re: AREAD question > > Because the AREAD enables building the built-in error trapping logic. If > the reg is too large or negative, it's trapped automatically. And, I > don't have to remember to change the limit edits every time I add > something to the branch table. > > Tony Thigpen > >
Re: [PossibleSpam] Re: AREAD question
CLFI? LOCTR?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Jon Perryman [jperr...@pacbell.net]
Sent: Monday, May 3, 2021 11:53 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: [PossibleSpam] Re: AREAD question
AREAD is not recommended for Tony's situation. Instead, follow the standard
assembler conventions and the code will be clean and readable for assembler.
Here is how I would implement Tony's PERFORM_ON macro.
Jon.
PERFORM_ON (R3),BAD_VALUE=ERRNO_2,BRTABLE=(
INITAPI, 00
ACCEPT,01
BIND, 02
CLOSE, 03
CONNECT, 04
FCNTL) 05
MACRO
PERFORM_ON ,_VALUE=,BRTABLE=
.* SAME AS PERFORM_ON
SETC 'A'
AIF ('_VALUE' EQ '' ).NOBV
SETC '_VALUE'
.NOBVANOP
STR15,R15_LASTNot sure why
MACPARM L,R15,
TMLLR15,3 Valid 4 byte offset?
JNZ Invalid, go abend
CLR15,=A(D) < 0 or > branch table size?
JH Invalid, go abend
L R15,B(R15)
BASR R14,R15 call function
J D
A DCX'' FORCE ABEND
B DS0F
SETA 1
.NEXTANOP
DCA(()) Branch table entry
SETA +1
AIF ( LT K').NEXT
D DS0H
MEND
Re: [PossibleSpam] Re: AREAD question
AREAD is not recommended for Tony's situation. Instead, follow the standard
assembler conventions and the code will be clean and readable for assembler.
Here is how I would implement Tony's PERFORM_ON macro.
Jon.
PERFORM_ON (R3),BAD_VALUE=ERRNO_2,BRTABLE=(
INITAPI, 00
ACCEPT, 01
BIND, 02
CLOSE, 03
CONNECT, 04
FCNTL) 05
MACRO
PERFORM_ON ,_VALUE=,BRTABLE=
.* SAME AS PERFORM_ON
SETC 'A'
AIF ('_VALUE' EQ '' ).NOBV
SETC '_VALUE'
.NOBV ANOP
ST R15,R15_LAST Not sure why
MACPARM L,R15,
TMLL R15,3 Valid 4 byte offset?
JNZ Invalid, go abend
CL R15,=A(D) < 0 or > branch table size?
JH Invalid, go abend
L R15,B(R15)
BASR R14,R15 call function
J D
A DC X'' FORCE ABEND
B DS 0F
SETA 1
.NEXT ANOP
DC A(()) Branch table entry
SETA +1
AIF ( LT K').NEXT
D DS 0H
MEND
Re: [PossibleSpam] Re: AREAD question
Thanks for the alignment issue. I went back and found that a DS 0H was in the code in some historical copies of the macro, but not in all the copies. I must have fat-fingered a line delete at some point. Also, the SOC1 is only if I did not tell the macro how to handle a bad value. With some of my code, I am just too deep in the levels and past all other edits. So, as such, there should "never" be a bad value. So, instead of having to set up a new message or returning up the code levels, I want an abend so I can actually review the dump and see what happened. I know too many programmers that say "it will never happen" and so don't put some sort of trap in "just in case". Eventually, they will get burnt. Many years ago, there was a piece of software that put out a message: "Call Joe at x and tell him he owes Bob $10". Bob had bet Joe that some condition could never occur, but it did. Bob got his $10. :-) Tony Thigpen Steve Smith wrote on 5/3/21 6:32 PM: There's no need for more parameters... just maybe a GBLA. Frankly, I think branch tables are simple enough to code, including automatic range checking, as to not be worth macros at all. Whatever. btw, HLASM is pretty smart, but it doesn't read your commentary: A DCX''FORCE ABEND | MUST BE TOGETHER FOR THE C DCY(*-B) | CL TEST TO WORK TT 050610 You have an unaligned constant in front of an aligned one, and they have to be together. Lucky for you they are until someone tweaks your macro. A DCA(*-B) ..is what you want. That oh-so-clever S0C1 for an out-of-range value will work just as well. sas On Mon, May 3, 2021 at 5:36 PM Seymour J Metz wrote: The same would be true if you used macro parameters. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Monday, May 3, 2021 5:24 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: [PossibleSpam] Re: AREAD question Because the AREAD enables building the built-in error trapping logic. If the reg is too large or negative, it's trapped automatically. And, I don't have to remember to change the limit edits every time I add something to the branch table. Tony Thigpen
Re: [PossibleSpam] Re: AREAD question
There's no need for more parameters... just maybe a GBLA. Frankly, I think branch tables are simple enough to code, including automatic range checking, as to not be worth macros at all. Whatever. btw, HLASM is pretty smart, but it doesn't read your commentary: A DCX''FORCE ABEND | MUST BE TOGETHER FOR THE C DCY(*-B) | CL TEST TO WORK TT 050610 You have an unaligned constant in front of an aligned one, and they have to be together. Lucky for you they are until someone tweaks your macro. A DCA(*-B) ..is what you want. That oh-so-clever S0C1 for an out-of-range value will work just as well. sas On Mon, May 3, 2021 at 5:36 PM Seymour J Metz wrote: > The same would be true if you used macro parameters. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Tony Thigpen [t...@vse2pdf.com] > Sent: Monday, May 3, 2021 5:24 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: [PossibleSpam] Re: AREAD question > > Because the AREAD enables building the built-in error trapping logic. If > the reg is too large or negative, it's trapped automatically. And, I > don't have to remember to change the limit edits every time I add > something to the branch table. > > Tony Thigpen > >
Re: [PossibleSpam] Re: AREAD question
The same would be true if you used macro parameters. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Monday, May 3, 2021 5:24 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: [PossibleSpam] Re: AREAD question Because the AREAD enables building the built-in error trapping logic. If the reg is too large or negative, it's trapped automatically. And, I don't have to remember to change the limit edits every time I add something to the branch table. Tony Thigpen Steve Smith wrote on 5/3/21 5:13 PM: > Why not just have a macro to generate each entry, and not mess with AREAD > at all? > > Like: > INITAPI PERF_ENT 00 > ACCEPT PERF_ENT 01 > ... > > Seems like you'd save a bunch of code, besides avoiding AREAD complications. > > sas > > > On Mon, May 3, 2021 at 5:03 PM Tony Thigpen wrote: > >> I use LOCTR heavily in my programs. Separate areas for base code, >> basr'ed to code, lits, acons, just to name a few. It will not help me >> with this issue. >> >> The following is the code that uses the AREAD macro that I am working >> with. The macro is attached. (I have trimmed down the source call a bit >> as the real one has a lot more entries in the table. >> >> PERFORM_ON (R3),BAD_VALUE=ERRNO_2 >> INITAPI 00 >> ACCEPT 01 >> BIND02 >> CLOSE 03 >> CONNECT 04 >> FCNTL 05 >> - >> >> In reality, I think this is a very appropriate use of AREAD and I am >> just stuck with only using the macro in real program code and not in >> another macro. >> >> Tony Thigpen >> >>
Re: [PossibleSpam] Re: AREAD question
Because the AREAD enables building the built-in error trapping logic. If the reg is too large or negative, it's trapped automatically. And, I don't have to remember to change the limit edits every time I add something to the branch table. Tony Thigpen Steve Smith wrote on 5/3/21 5:13 PM: Why not just have a macro to generate each entry, and not mess with AREAD at all? Like: INITAPI PERF_ENT 00 ACCEPT PERF_ENT 01 ... Seems like you'd save a bunch of code, besides avoiding AREAD complications. sas On Mon, May 3, 2021 at 5:03 PM Tony Thigpen wrote: I use LOCTR heavily in my programs. Separate areas for base code, basr'ed to code, lits, acons, just to name a few. It will not help me with this issue. The following is the code that uses the AREAD macro that I am working with. The macro is attached. (I have trimmed down the source call a bit as the real one has a lot more entries in the table. PERFORM_ON (R3),BAD_VALUE=ERRNO_2 INITAPI 00 ACCEPT 01 BIND02 CLOSE 03 CONNECT 04 FCNTL 05 - In reality, I think this is a very appropriate use of AREAD and I am just stuck with only using the macro in real program code and not in another macro. Tony Thigpen
Re: [PossibleSpam] Re: AREAD question
Why not just have a macro to generate each entry, and not mess with AREAD at all? Like: INITAPI PERF_ENT 00 ACCEPT PERF_ENT 01 ... Seems like you'd save a bunch of code, besides avoiding AREAD complications. sas On Mon, May 3, 2021 at 5:03 PM Tony Thigpen wrote: > I use LOCTR heavily in my programs. Separate areas for base code, > basr'ed to code, lits, acons, just to name a few. It will not help me > with this issue. > > The following is the code that uses the AREAD macro that I am working > with. The macro is attached. (I have trimmed down the source call a bit > as the real one has a lot more entries in the table. > >PERFORM_ON (R3),BAD_VALUE=ERRNO_2 > INITAPI 00 > ACCEPT 01 > BIND02 > CLOSE 03 > CONNECT 04 > FCNTL 05 > - > > In reality, I think this is a very appropriate use of AREAD and I am > just stuck with only using the macro in real program code and not in > another macro. > > Tony Thigpen > >
Re: [PossibleSpam] Re: AREAD question
I use LOCTR heavily in my programs. Separate areas for base code,
basr'ed to code, lits, acons, just to name a few. It will not help me
with this issue.
The following is the code that uses the AREAD macro that I am working
with. The macro is attached. (I have trimmed down the source call a bit
as the real one has a lot more entries in the table.
PERFORM_ON (R3),BAD_VALUE=ERRNO_2
INITAPI 00
ACCEPT 01
BIND02
CLOSE 03
CONNECT 04
FCNTL 05
-
In reality, I think this is a very appropriate use of AREAD and I am
just stuck with only using the macro in real program code and not in
another macro.
Tony Thigpen
Seymour J Metz wrote on 5/3/21 4:43 PM:
Depending on what you're doing, LOCTR may help.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Tony Thigpen [t...@vse2pdf.com]
Sent: Monday, May 3, 2021 3:52 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: [PossibleSpam] Re: AREAD question
In this case, I am using AREAD to build a branch table. The macro first
edits the value passed based on the number of entries in the branch
table. It needs knows how many entries by reading branch_to points. (It
also builds the table while it is reading/counting the number of
entries.) The number of entries can easily be over 60 in many of my
programs.
Tony Thigpen
Jon Perryman wrote on 5/3/21 3:06 PM:
AREAD is intended for reading the source file. Although there are
workarounds, I personally avoid them because you can run into problems with
macros that use aread. As you mentioned, SETC to a global variable is a good
option to pass information.
What are the negative issues you encountered with SETC? I've written a lot of
macro's and never had an issue. Sometimes it's more work than I would like but
still manageable. For instance, do you really need AREAD or would temporarily
override opcodes work?
Jon.
On Monday, May 3, 2021, 08:31:25 AM PDT, Tony Thigpen
wrote:
I have several macros that use AREAD. But, I tried something this
weekend that I still have not figured out. Maybe someone has a suggestion.
I also use macros as a way to include large blocks of common code in
programs. I tried to create such a macro from some code that used one of
my macros that used AREAD. I found that the use of AREAD in the
lower-level macro actually read from the 'top level' program source, not
from the source in the 'next-up' macro.
The doc does indicated that this would happen:
"...from the records in the primary input
stream that follow immediately after the macro instruction."
So, it looks like the only way to use an AREAD and read from an 'higher
level' macro, would be to have the higher level macro push the info to
be read into the buffer using AINSERT. Not as 'nice'.
Did I miss some other option?
(Before you suggest COPY vs. macros for common code, I usually include
parms to the common code. I can re-work that logic using .SETC, etc.,
but that has some negative issues I would need to think about before
doing so.)
Tony Thigpen
MACRO
PERFORM_ON ,_VALUE=
.* SAME AS PERFORM_ON
SETC 'A'
AIF ('_VALUE' EQ '' ).NOBV
SETC '_VALUE'
.NOBVANOP
STR15,R15_LAST
MACPARM L,R15,
CLR15,AMUST BE LOGICAL, NOT NBR COMPARE
BH . BRANCHES FOR BOTH HIGH & MINUS
LAR14,3
NRR14,R15
*LTR R0,R0 CC SET BY NR TT 082712
BNZ
L R15,B(R15)
LTR R15,R15
BZ
BASR R14,R15
B D
B DS0F
.READANOP
AREAD NOSTMT
SETC ''(16,39)
SETC ''(40,30)
AIF (''(1,1) EQ '*').READ
AIF (''(16,1) EQ '-').CARDEND
AIF (''(16,1) EQ ' ').INVALID
AIF (''(16,3) EQ 'N/A').INVALID
SETA 1
.GETFLD AIF (''(+1,1) EQ ' ').STORE
SETA +1
AGO .GETFLD
.INVALID ANOP
SETA 1
SETC '0'
.STORE ANOP
SETC ''(1,)
SETC 'A() '(1,24)
DC
AGO .READ
.CARDEND ANOP
A DCX''FORCE ABEND | MUST BE TOGETHER FOR THE
C DCY(*-B) | CL TEST TO WORK TT 050610
D DS0H
MEND
Re: [PossibleSpam] Re: AREAD question
Depending on what you're doing, LOCTR may help. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Monday, May 3, 2021 3:52 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: [PossibleSpam] Re: AREAD question In this case, I am using AREAD to build a branch table. The macro first edits the value passed based on the number of entries in the branch table. It needs knows how many entries by reading branch_to points. (It also builds the table while it is reading/counting the number of entries.) The number of entries can easily be over 60 in many of my programs. Tony Thigpen Jon Perryman wrote on 5/3/21 3:06 PM: > AREAD is intended for reading the source file. Although there are > workarounds, I personally avoid them because you can run into problems with > macros that use aread. As you mentioned, SETC to a global variable is a good > option to pass information. > What are the negative issues you encountered with SETC? I've written a lot of > macro's and never had an issue. Sometimes it's more work than I would like > but still manageable. For instance, do you really need AREAD or would > temporarily override opcodes work? > Jon. > On Monday, May 3, 2021, 08:31:25 AM PDT, Tony Thigpen > wrote: > > I have several macros that use AREAD. But, I tried something this > weekend that I still have not figured out. Maybe someone has a suggestion. > > I also use macros as a way to include large blocks of common code in > programs. I tried to create such a macro from some code that used one of > my macros that used AREAD. I found that the use of AREAD in the > lower-level macro actually read from the 'top level' program source, not > from the source in the 'next-up' macro. > > The doc does indicated that this would happen: > "...from the records in the primary input > stream that follow immediately after the macro instruction." > > So, it looks like the only way to use an AREAD and read from an 'higher > level' macro, would be to have the higher level macro push the info to > be read into the buffer using AINSERT. Not as 'nice'. > > Did I miss some other option? > > (Before you suggest COPY vs. macros for common code, I usually include > parms to the common code. I can re-work that logic using .SETC, etc., > but that has some negative issues I would need to think about before > doing so.) > > > > Tony Thigpen > >
Re: [PossibleSpam] Re: AREAD question
In this case, I am using AREAD to build a branch table. The macro first edits the value passed based on the number of entries in the branch table. It needs knows how many entries by reading branch_to points. (It also builds the table while it is reading/counting the number of entries.) The number of entries can easily be over 60 in many of my programs. Tony Thigpen Jon Perryman wrote on 5/3/21 3:06 PM: AREAD is intended for reading the source file. Although there are workarounds, I personally avoid them because you can run into problems with macros that use aread. As you mentioned, SETC to a global variable is a good option to pass information. What are the negative issues you encountered with SETC? I've written a lot of macro's and never had an issue. Sometimes it's more work than I would like but still manageable. For instance, do you really need AREAD or would temporarily override opcodes work? Jon. On Monday, May 3, 2021, 08:31:25 AM PDT, Tony Thigpen wrote: I have several macros that use AREAD. But, I tried something this weekend that I still have not figured out. Maybe someone has a suggestion. I also use macros as a way to include large blocks of common code in programs. I tried to create such a macro from some code that used one of my macros that used AREAD. I found that the use of AREAD in the lower-level macro actually read from the 'top level' program source, not from the source in the 'next-up' macro. The doc does indicated that this would happen: "...from the records in the primary input stream that follow immediately after the macro instruction." So, it looks like the only way to use an AREAD and read from an 'higher level' macro, would be to have the higher level macro push the info to be read into the buffer using AINSERT. Not as 'nice'. Did I miss some other option? (Before you suggest COPY vs. macros for common code, I usually include parms to the common code. I can re-work that logic using .SETC, etc., but that has some negative issues I would need to think about before doing so.) Tony Thigpen
