Re: Generating a TR field
On May 29, 2022, at 08:13:16, Seymour J Metz wrote:
>
> I've run into IBM macros where there is an optional first parameter and a
> null value causes an error message; In such cases I've had to put a comment
> statement before or after the macro call to comment it. Too bad that there
> isn't a with the effect of treating the operand as missing rather
> than empty, e.g., "label FOO " would get 0 as N'
>
Are you willing to identify a specific example and its origin?
("IBM" or "non-IBM" might suffice.)
What about a couple RCFs?:
To the macro caller:
... Note that the comma causes two operands to bee passed to
the macro, possibly causing a syntax error.
To the macro author:
The solitary comma in the operands field recommended earlier
will appear as two null operands. Your macro should be prepared
To deal with this.
--
gil
Re: Generating a TR field
Not silly, and in fact necessary. If you're generating a variable length list
in which null entries are valid, discarding trailing null arguments would
generate erroneous code. Even if you had a convention for explicitly null
entries, you'd need a counting loop instead of using the N attribute, making
the code longer and less clear.
--
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: Sunday, May 29, 2022 2:35 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Generating a TR field
Well, it's a moot point whether it was a good idea for HLASM to treat a
null operand and a non-existent one differently. They can't change it now,
without yet another silly option to allow them to act the same way.
Regardless, it is a mistake for a macro to bleat out an error because an
optional parameter is null. It's trivial to allow null to be equivalent to
non-specified. In fact, AIF ('' EQ '') covers both.
It is certainly possible for a macro to be designed to treat non-specified
and null both as valid, but with different semantics. Although I doubt
that's a good idea.
sas
>
>
Re: Generating a TR field
I maintain code written in HLASM, but I don't maintain HLASM itself -- I'm not sure which one you meant. I understand the distinction between two operands and no operands, but I have yet to encounter a case where it mattered. Others have said that they have had problems with macros that make such a distinction, so I don't claim that they don't exist, but I have never experienced the problem myself. - mb > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Paul Gilmartin > Sent: Sunday, May 29, 2022 2:27 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: [EXTERNAL] Re: Generating a TR field > > On May 29, 2022, at 12:16:50, Seymour J Metz wrote: > > > > The assembler lets a macro determine how many positional parameters are > in the macro invocation. If there is a validity check on the positional > parameters, using N', then the macro may treat an empty parameter > as an invalid parameter. ... > > > > > From: Mark Boonie [???@US.IBM.COM] > > Sent: Sunday, May 29, 2022 1:58 PM > > ... > > One of the reasons it's important to explicitly indicate that no > operands are present is to prevent future maintenance from breaking > programs that currently assemble correctly. ... > > > That comma indicates not zero operands, but two operands. > Try it. > > Are you a HLASM maintainer? > > -- > gil
Re: Generating a TR field
There are legitimate reasons to write macros with a variable number of
parameters that allow zero parameters. While such macros could certainly test
for a special end-of-list token, that is a clunky ad-hoc solution for both the
author and the user; I'd rather see a standard solution.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Mark Boonie [boo...@us.ibm.com]
Sent: Sunday, May 29, 2022 2:31 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Generating a TR field
Fortunately I've never seen a macro coded like that, although it certainly
seems possible. However, I would consider that to be a demented flaw in the
macro design rather than the language. I do see your point, though, about
wanting some construct that would always indicate the start of the remarks
without implying the existence of any parameters. Personally, I would consider
the comma to be that construct and do everything in my power to avoid using any
macro that exhibit the behavior you described, if in fact I ever encountered
one (which I think is highly unlikely).
- mb
> -Original Message-
> From: IBM Mainframe Assembler List On
> Behalf Of Seymour J Metz
> Sent: Sunday, May 29, 2022 2:17 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: [EXTERNAL] Re: Generating a TR field
>
> The assembler lets a macro determine how many positional parameters are in
> the macro invocation. If there is a validity check on the positional
> parameters, using N', then the macro may treat an empty parameter
> as an invalid parameter. Consider
>
> MACRO
> BAR
> DCA(N')
>SETA 0
> .NEXTAIF ( EQ N').END
>SETA +1
> AIF ('()' EQ 'YES').TRUE
> AIF ('()' EQ 'FALSE').FALSE
> MNOTE 8,'PARAMETER IS NOT TRUE OR FALSE'
> MEXIT
> .TRUEDC X'1'
> AGO .NEXT
> .FALSE DCX'0'
> AGO NEXT
> MEND
>
> Then "GOOD BAR" is valid but "BAD BAR ," will produce an error message.
>
> Note: I haven't actually tried it.
Re: Generating a TR field
Well, it's a moot point whether it was a good idea for HLASM to treat a
null operand and a non-existent one differently. They can't change it now,
without yet another silly option to allow them to act the same way.
Regardless, it is a mistake for a macro to bleat out an error because an
optional parameter is null. It's trivial to allow null to be equivalent to
non-specified. In fact, AIF ('' EQ '') covers both.
It is certainly possible for a macro to be designed to treat non-specified
and null both as valid, but with different semantics. Although I doubt
that's a good idea.
sas
>
>
Re: Generating a TR field
Fortunately I've never seen a macro coded like that, although it certainly
seems possible. However, I would consider that to be a demented flaw in the
macro design rather than the language. I do see your point, though, about
wanting some construct that would always indicate the start of the remarks
without implying the existence of any parameters. Personally, I would consider
the comma to be that construct and do everything in my power to avoid using any
macro that exhibit the behavior you described, if in fact I ever encountered
one (which I think is highly unlikely).
- mb
> -Original Message-
> From: IBM Mainframe Assembler List On
> Behalf Of Seymour J Metz
> Sent: Sunday, May 29, 2022 2:17 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: [EXTERNAL] Re: Generating a TR field
>
> The assembler lets a macro determine how many positional parameters are in
> the macro invocation. If there is a validity check on the positional
> parameters, using N', then the macro may treat an empty parameter
> as an invalid parameter. Consider
>
> MACRO
> BAR
> DCA(N')
>SETA 0
> .NEXTAIF ( EQ N').END
>SETA +1
> AIF ('()' EQ 'YES').TRUE
> AIF ('()' EQ 'FALSE').FALSE
> MNOTE 8,'PARAMETER IS NOT TRUE OR FALSE'
> MEXIT
> .TRUEDC X'1'
> AGO .NEXT
> .FALSE DCX'0'
> AGO NEXT
> MEND
>
> Then "GOOD BAR" is valid but "BAD BAR ," will produce an error message.
>
> Note: I haven't actually tried it.
Re: Generating a TR field
On May 29, 2022, at 12:16:50, Seymour J Metz wrote: > > The assembler lets a macro determine how many positional parameters are in > the macro invocation. If there is a validity check on the positional > parameters, using N', then the macro may treat an empty parameter as > an invalid parameter. ... > > From: Mark Boonie [???@US.IBM.COM] > Sent: Sunday, May 29, 2022 1:58 PM > ... > One of the reasons it's important to explicitly indicate that no operands are > present is to prevent future maintenance from breaking programs that > currently assemble correctly. ... > That comma indicates not zero operands, but two operands. Try it. Are you a HLASM maintainer? -- gil
Re: Generating a TR field
The assembler lets a macro determine how many positional parameters are in the
macro invocation. If there is a validity check on the positional parameters,
using N', then the macro may treat an empty parameter as an invalid
parameter. Consider
MACRO
BAR
DCA(N')
SETA 0
.NEXTAIF ( EQ N').END
SETA +1
AIF ('()' EQ 'YES').TRUE
AIF ('()' EQ 'FALSE').FALSE
MNOTE 8,'PARAMETER IS NOT TRUE OR FALSE'
MEXIT
.TRUEDC X'1'
AGO .NEXT
.FALSE DCX'0'
AGO NEXT
MEND
Then "GOOD BAR" is valid but "BAD BAR ," will produce an error message.
Note: I haven't actually tried it.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Mark Boonie [boo...@us.ibm.com]
Sent: Sunday, May 29, 2022 1:58 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Generating a TR field
I didn't quite understand your point about one of the two macros being valid,
so I apologize if I'm stating the obvious. I think the problem you're
describing stems from the fact that in HLASM, the remarks for a given line
begin after the operand entry for that line ends. If you have an operation
entry that has optional operands, how do you indicate that the remaining
characters on the line are an operand entry or a remarks entry? Conventionally
it's done by providing the comma to indicate that the operands are not being
supplied and defaults are to be used. This is why the first three of these
statements assemble correctly but the remaining ones do not:
SPACE
SPACE 1 Comments
SPACE , Comments
SPACE Comments
SPACE
SPACE 2022 is when this code was written
Well, the last statement may assemble without error, but it probably isn't what
the user intended.
One of the reasons it's important to explicitly indicate that no operands are
present is to prevent future maintenance from breaking programs that currently
assemble correctly. Suppose I have a macro that has no operands today and is
coded like this:
MYMAC This is my trivial comment
If MYMAC is enhanced to accept an optional positional parameter that can only
be YES or NO, this macro would (or should) now be flagged as erroneously coded
because the first parameter, "This", is incorrect. Using a comma in the
operands entry allows the person enhancing the macro to provide a default for a
new operand.
- mb
> ObSyntaxRant There are languages where it is always possible to add a
> comment at the end of a statement; why does HLASM require a delimiter that
> is not always permissible? If it's the only way to add a comment, why
> should one of these be valid and the other not
>
> labelFOO , comment
> labelBAR , comment
>
> where FOO has optional positional parameters and BAR has no positional
> parameters.
Re: Generating a TR field
On May 29, 2022, at 08:13:16, Seymour J Metz wrote: > > I've run into IBM macros where there is an optional first parameter and a > null value causes an error message; In such cases I've had to put a comment > statement before or after the macro call to comment it. > Ouch! Would an IBM representative care to comment on this manifest conflict with established coding practice. An RFC that the doc each such sensitive macro must contain: "Attention: Don't use the comma!" Or an RFE for each such macro to treat N'=2 wit two null parameters as if =''. Are there any macros that make a meaningful distinction between Two null parameters and no parameter, but not indicate an error? Or an RFE to HLASM that an operand field, before lexical transformation, containing a siingle character "," be treated as no parameters: label FOO , Comment but no parameter label FOO '', Comment with two null parameters. Do not make this YA option! > Too bad that there isn't a with the effect of treating the > operand as missing rather than empty, e.g., "label FOO " would get > 0 as N' > The Algol 68 analogue is SKIP. Is "" a reserved symbol prefix? Prudent programmers should replace every comma at risk with , even on instruction mnemonics, lest they be front-ended with macros. Esthetic violence! Column 72 restrictions! -- Ouch! gil
Re: Generating a TR field
I didn't quite understand your point about one of the two macros being valid, so I apologize if I'm stating the obvious. I think the problem you're describing stems from the fact that in HLASM, the remarks for a given line begin after the operand entry for that line ends. If you have an operation entry that has optional operands, how do you indicate that the remaining characters on the line are an operand entry or a remarks entry? Conventionally it's done by providing the comma to indicate that the operands are not being supplied and defaults are to be used. This is why the first three of these statements assemble correctly but the remaining ones do not: SPACE SPACE 1 Comments SPACE , Comments SPACE Comments SPACE SPACE 2022 is when this code was written Well, the last statement may assemble without error, but it probably isn't what the user intended. One of the reasons it's important to explicitly indicate that no operands are present is to prevent future maintenance from breaking programs that currently assemble correctly. Suppose I have a macro that has no operands today and is coded like this: MYMAC This is my trivial comment If MYMAC is enhanced to accept an optional positional parameter that can only be YES or NO, this macro would (or should) now be flagged as erroneously coded because the first parameter, "This", is incorrect. Using a comma in the operands entry allows the person enhancing the macro to provide a default for a new operand. - mb > ObSyntaxRant There are languages where it is always possible to add a > comment at the end of a statement; why does HLASM require a delimiter that > is not always permissible? If it's the only way to add a comment, why > should one of these be valid and the other not > > labelFOO , comment > labelBAR , comment > > where FOO has optional positional parameters and BAR has no positional > parameters.
Re: Generating a TR field
I've run into IBM macros where there is an optional first parameter and a null value causes an error message; In such cases I've had to put a comment statement before or after the macro call to comment it. Too bad that there isn't a with the effect of treating the operand as missing rather than empty, e.g., "label FOO " would get 0 as N' In PL/I and REXX I've certainly put comments in the middle of statements when I believed that they were appropriate, but at least being able to always add them at the end would still be a step forward. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Sunday, May 29, 2022 10:00 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Generating a TR field On May 29, 2022, at 03:47:43, Seymour J Metz wrote: > > Here there be dragons. Comments that explain what is already clear can > clutter the code and make it harder to read. > +1 On occasion I have deleted comments so could read the code. > ObSyntaxRant There are languages where it is always possible to add a comment > at the end of a statement; > Or even within a statement: "A /* targeet */ = /* assignment */ 42 /* expression */" I've done this to document complicated subexpressions. > why does HLASM require a delimiter that is not always permissible? If it's > the only way to add a comment, why should one of these be valid and the other > not > > labelFOO , comment > labelBAR , comment > > where FOO has optional positional parameters and BAR has no positional > parameters. > Have you an example in an assembler instruction? It might affect N' in user-written macros that validate every operand. A co-workeer's code, IIRC "PRINT ,,,GEN" was flagged as an error by an ISV cross assembler. "But it works in HLASM! I think it's positional." "RTFM say it's an error." SR on HLASM. Closed DOC. The ISV accommodated the newly documented construct. I've known an assembler that used ";", hot otherwise used in The language, to start a line comment. -- gil
Re: Generating a TR field
On May 29, 2022, at 03:47:43, Seymour J Metz wrote: > > Here there be dragons. Comments that explain what is already clear can > clutter the code and make it harder to read. > +1 On occasion I have deleted comments so could read the code. > ObSyntaxRant There are languages where it is always possible to add a comment > at the end of a statement; > Or even within a statement: "A /* targeet */ = /* assignment */ 42 /* expression */" I've done this to document complicated subexpressions. > why does HLASM require a delimiter that is not always permissible? If it's > the only way to add a comment, why should one of these be valid and the other > not > > labelFOO , comment > labelBAR , comment > > where FOO has optional positional parameters and BAR has no positional > parameters. > Have you an example in an assembler instruction? It might affect N' in user-written macros that validate every operand. A co-workeer's code, IIRC "PRINT ,,,GEN" was flagged as an error by an ISV cross assembler. "But it works in HLASM! I think it's positional." "RTFM say it's an error." SR on HLASM. Closed DOC. The ISV accommodated the newly documented construct. I've known an assembler that used ";", hot otherwise used in The language, to start a line comment. -- gil
Re: Generating a TR field
Here there be dragons. Comments that explain what is already clear can clutter the code and make it harder to read. By all means document adequately, but don't simply echo the semantics of the code for the purported benefit of newbies. Even newbies can be distracted by unnecessary comments. ObSyntaxRant There are languages where it is always possible to add a comment at the end of a statement; why does HLASM require a delimiter that is not always permissible? If it's the only way to add a comment, why should one of these be valid and the other not labelFOO , comment labelBAR , comment where FOO has optional positional parameters and BAR has no positional parameters. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Friday, May 27, 2022 11:31 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Generating a TR field On May 26, 2022, at 16:26:38, Charles Mills wrote: > > And what is that? Some comments? > My thought, but what?: A paraphrase of the OP's requirement? And/or explanation of the unintuitive semantics of: o "*" within a repetitive constant definition? o A character self-defining term used as a numeric value? o "ORG" with *two* empty arguments? But no fault to Ed. His target was a level above your putative "maintenance newbie" and valued brevity. >> @Ed's approach is elegant, although a maintenance newbie might have > trouble understanding what 256AL1(*-TABLE) did. >> > Troublesome only because Ed left out the most important thing. > >> -Original Message- >> From: Ed Jaffe >> Sent: Thursday, May 26, 2022 2:36 PM >> >> What you want should be trivial: >> |TABLE DC 256AL1(*-TABLE) >> | ORG TABLE+C'*' >> | DC CL1' ' >> | ORG , > > -- > gil -- gil Моё судно на воздушной подушке полно угрей.
Re: Generating a TR field
Ed might have prioritized brevity because he's not paid to do your coding for you. His example is idiomatic for an experienced developer, and if you're not experienced, then you have a learning opportunity. I have no patience with the fear that a "maintenance newbie" can't be expected to learn anything. If they can't, I suggest you'd be better off with not doing maintenance until you find someone who can. sas On Fri, May 27, 2022 at 11:32 AM Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On May 26, 2022, at 16:26:38, Charles Mills wrote: > > > > And what is that? Some comments? > > > My thought, but what?: > A paraphrase of the OP's requirement? > And/or explanation of the unintuitive semantics of: > o "*" within a repetitive constant definition? > o A character self-defining term used as a numeric value? > o "ORG" with *two* empty arguments? > > But no fault to Ed. His target was a level above your > putative "maintenance newbie" and valued brevity. > >
Re: Generating a TR field
On May 27, 2022, at 10:08:37, Charles Mills wrote: > > ORG , is not two empty arguments. It is one empty argument, with a comma so > that the first word of any comment does not get taken as an argument. > This was discussed here long ago and the experts agreed that for macros at least: MYMAC , perceives two empty arguments. One before the comma and one after. No arguments: MYMAC One argument: MYMAC FOO Two arguments: MYMAC FOO, Two arguments: MYMAC , > ORG Get back where we were > There's no way to make "ORG" report its operand count. > Would give you an error on "Get" (unless GET happened to be a valid label, > which would yield a really obscure result!). > ... or the comment were indented beyond the limit of the operand field. (I used to rely on that.) -- gil
Re: Generating a TR field
ORG , is not two empty arguments. It is one empty argument, with a comma so that the first word of any comment does not get taken as an argument. ORG Get back where we were Would give you an error on "Get" (unless GET happened to be a valid label, which would yield a really obscure result!). Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, May 27, 2022 8:32 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Generating a TR field On May 26, 2022, at 16:26:38, Charles Mills wrote: > > And what is that? Some comments? > My thought, but what?: A paraphrase of the OP's requirement? And/or explanation of the unintuitive semantics of: o "*" within a repetitive constant definition? o A character self-defining term used as a numeric value? o "ORG" with *two* empty arguments? But no fault to Ed. His target was a level above your putative "maintenance newbie" and valued brevity. >> @Ed's approach is elegant, although a maintenance newbie might have > trouble understanding what 256AL1(*-TABLE) did. >> > Troublesome only because Ed left out the most important thing. > >> -Original Message- >> From: Ed Jaffe >> Sent: Thursday, May 26, 2022 2:36 PM >> >> What you want should be trivial: >> |TABLE DC 256AL1(*-TABLE) >> | ORG TABLE+C'*' >> | DC CL1' ' >> | ORG , > > -- > gil -- gil Моё судно на воздушной подушке полно угрей.
Re: Generating a TR field
On May 26, 2022, at 16:26:38, Charles Mills wrote: > > And what is that? Some comments? > My thought, but what?: A paraphrase of the OP's requirement? And/or explanation of the unintuitive semantics of: o "*" within a repetitive constant definition? o A character self-defining term used as a numeric value? o "ORG" with *two* empty arguments? But no fault to Ed. His target was a level above your putative "maintenance newbie" and valued brevity. >> @Ed's approach is elegant, although a maintenance newbie might have > trouble understanding what 256AL1(*-TABLE) did. >> > Troublesome only because Ed left out the most important thing. > >> -Original Message- >> From: Ed Jaffe >> Sent: Thursday, May 26, 2022 2:36 PM >> >> What you want should be trivial: >> |TABLE DC 256AL1(*-TABLE) >> | ORG TABLE+C'*' >> | DC CL1' ' >> | ORG , > > -- > gil -- gil Моё судно на воздушной подушке полно угрей.
Re: Generating a TR field
Ooh, that is slick. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ed Jaffe Sent: Thursday, May 26, 2022 4:36 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Generating a TR field On 5/26/2022 2:23 PM, Schmitt, Michael wrote: > I want to replace all '*' with a space in a field. That's a TR instruction, > right? But when I search through our 40 years of assembler code, I see no > uses of TR for such a purpose. > > I thinking this is because of difficulty in building the TR table. We'd need > to have 256 bytes where every byte's value in in ascending sequence: 00 01 02 > 03 04 05 06 07 08 09 0A etc, right? Except for the byte at offset x'5C', > which would have the value x'40'. > > Is there a slick way or a macro to build the TR table? Or do people just code > a TRT loop instead, since it is easier to build a TRT table? What you want should be trivial: |TABLE DC 256AL1(*-TABLE) | ORG TABLE+C'*' | DC CL1' ' | ORG , -- Phoenix Software International Edward E. Jaffe Chief Technology Officer 831 Parkview Drive North El Segundo, CA 90245 https://clicktime.symantec.com/34nkAJv9vEbU9Adab4NCjkQ7VN?u=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: Generating a TR field
@Ed's approach is elegant, although a maintenance newbie might have trouble understanding what
256AL1(*-TABLE) did.
Ed’s technique is standard practice here for building such a table.
As for newbies who may be unclear about the machine code that this generates:
“Use the listing, Luke, use the LISTING!”
(with PRINT GEN, of course)
[Worth repeating ‘till they get how useful the listing is]
I also googled 256al1(*-
The 1st result (http://www.simotime.com) required a "find" (ctrl-f) for "256al1" to locate the
detailed description of creating a table that way.
The 2nd result (http://csc.columbusstate.edu/woolbright/TR.HTM)
gives all the detail required to address the OP's task/request:
"I want to replace all '*' with a space (" ") in a field."
"Is there a slick way .. to build the TR table."
Cheers to all,
Graeme
ASE P/L
On 27/05/2022 7:52 am, Charles Mills wrote:
All of the above.
A run-time loop would be trivial, and if executed once per run would not use
noticeable CPU.
A macro that used an incremented LCLA would be straightforward.
@Ed's approach is elegant, although a maintenance newbie might have trouble
understanding what 256AL1(*-TABLE) did.
If the field is expected to be all, say, uppercase alphanumeric, and you could
live with anything else being translated to SUB or ? or something like that,
then hand-coding the table would not be too onerous.
There are probably other arguably reasonable approaches.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Ed Jaffe
Sent: Thursday, May 26, 2022 2:36 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Generating a TR field
On 5/26/2022 2:23 PM, Schmitt, Michael wrote:
I want to replace all '*' with a space in a field. That's a TR instruction,
right? But when I search through our 40 years of assembler code, I see no uses
of TR for such a purpose.
I thinking this is because of difficulty in building the TR table. We'd need to
have 256 bytes where every byte's value in in ascending sequence: 00 01 02 03
04 05 06 07 08 09 0A etc, right? Except for the byte at offset x'5C', which
would have the value x'40'.
Is there a slick way or a macro to build the TR table? Or do people just code a
TRT loop instead, since it is easier to build a TRT table?
What you want should be trivial:
|TABLE DC 256AL1(*-TABLE)
| ORG TABLE+C'*'
| DC CL1' '
| ORG ,
Re: Generating a TR field
- Original Message - From: "Schmitt, Michael" To: Sent: Friday, May 27, 2022 7:23 AM I want to replace all '*' with a space in a field. That's a TR instruction, right? But when I search through our 40 years of assembler code, I see no uses of TR for such a purpose. What? That's what TR does, viz, replace one or more characters with others. I thinking this is because of difficulty in building the TR table. We'd need to have 256 bytes where every byte's value in in ascending sequence: 00 01 02 03 04 05 06 07 08 09 0A etc, right? Except for the byte at offset x'5C', which would have the value x'40'. Is there a slick way or a macro to build the TR table? Or do people just code a TRT loop instead, since it is easier to build a TRT table? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Generating a TR field
On 2022-05-26 19:08 PM, Charles Mills wrote: OP did not ask how to do the translate. OP asked Is there a slick way or a macro to build the TR table? True. I should leave it to Gil. -- 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: Generating a TR field
OP did not ask how to do the translate. OP asked > Is there a slick way or a macro to build the TR table? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Gord Tomlin Sent: Thursday, May 26, 2022 3:46 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Generating a TR field On 2022-05-26 18:26 PM, Charles Mills wrote: > And what is that? Some comments? Probably the actual TR instruction. -- 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: Generating a TR field
On 2022-05-26 18:26 PM, Charles Mills wrote: And what is that? Some comments? Probably the actual TR instruction. -- 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: Generating a TR field
And what is that? Some comments? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, May 26, 2022 3:08 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Generating a TR field On May 26, 2022, at 15:52:08, Charles Mills wrote: > > @Ed's approach is elegant, although a maintenance newbie might have trouble understanding what 256AL1(*-TABLE) did. > Troublesome only because Ed left out the most important thing. > -Original Message- > From: Ed Jaffe > Sent: Thursday, May 26, 2022 2:36 PM > > What you want should be trivial: > |TABLE DC 256AL1(*-TABLE) > | ORG TABLE+C'*' > | DC CL1' ' > | ORG , -- gil
Re: Generating a TR field
On May 26, 2022, at 15:52:08, Charles Mills wrote: > > @Ed's approach is elegant, although a maintenance newbie might have trouble > understanding what 256AL1(*-TABLE) did. > Troublesome only because Ed left out the most important thing. > -Original Message- > From: Ed Jaffe > Sent: Thursday, May 26, 2022 2:36 PM > > What you want should be trivial: > |TABLE DC 256AL1(*-TABLE) > | ORG TABLE+C'*' > | DC CL1' ' > | ORG , -- gil
Re: Generating a TR field
Heck, doing it the hardest way possible would not be terribly burdensome. Code one line DC X'00',X'01',X'02',...,X'0F' Repro that 15 times. Then using an editor select the first repro line and change all '0 to '1, then on the next line all '0 to '2, and so forth. Finally overtype 40 where the 5C is. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Thursday, May 26, 2022 2:52 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Generating a TR field All of the above. A run-time loop would be trivial, and if executed once per run would not use noticeable CPU. A macro that used an incremented LCLA would be straightforward. @Ed's approach is elegant, although a maintenance newbie might have trouble understanding what 256AL1(*-TABLE) did. If the field is expected to be all, say, uppercase alphanumeric, and you could live with anything else being translated to SUB or ? or something like that, then hand-coding the table would not be too onerous. There are probably other arguably reasonable approaches. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ed Jaffe Sent: Thursday, May 26, 2022 2:36 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Generating a TR field On 5/26/2022 2:23 PM, Schmitt, Michael wrote: > I want to replace all '*' with a space in a field. That's a TR instruction, > right? But when I search through our 40 years of assembler code, I see no > uses of TR for such a purpose. > > I thinking this is because of difficulty in building the TR table. We'd need > to have 256 bytes where every byte's value in in ascending sequence: 00 01 02 > 03 04 05 06 07 08 09 0A etc, right? Except for the byte at offset x'5C', > which would have the value x'40'. > > Is there a slick way or a macro to build the TR table? Or do people just code > a TRT loop instead, since it is easier to build a TRT table? What you want should be trivial: |TABLE DC 256AL1(*-TABLE) | ORG TABLE+C'*' | DC CL1' ' | ORG , -- Phoenix Software International Edward E. Jaffe Chief Technology Officer 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: Generating a TR field
All of the above. A run-time loop would be trivial, and if executed once per run would not use noticeable CPU. A macro that used an incremented LCLA would be straightforward. @Ed's approach is elegant, although a maintenance newbie might have trouble understanding what 256AL1(*-TABLE) did. If the field is expected to be all, say, uppercase alphanumeric, and you could live with anything else being translated to SUB or ? or something like that, then hand-coding the table would not be too onerous. There are probably other arguably reasonable approaches. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ed Jaffe Sent: Thursday, May 26, 2022 2:36 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Generating a TR field On 5/26/2022 2:23 PM, Schmitt, Michael wrote: > I want to replace all '*' with a space in a field. That's a TR instruction, > right? But when I search through our 40 years of assembler code, I see no > uses of TR for such a purpose. > > I thinking this is because of difficulty in building the TR table. We'd need > to have 256 bytes where every byte's value in in ascending sequence: 00 01 02 > 03 04 05 06 07 08 09 0A etc, right? Except for the byte at offset x'5C', > which would have the value x'40'. > > Is there a slick way or a macro to build the TR table? Or do people just code > a TRT loop instead, since it is easier to build a TRT table? What you want should be trivial: |TABLE DC 256AL1(*-TABLE) | ORG TABLE+C'*' | DC CL1' ' | ORG , -- Phoenix Software International Edward E. Jaffe Chief Technology Officer 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: Generating a TR field
On 5/26/2022 2:23 PM, Schmitt, Michael wrote: I want to replace all '*' with a space in a field. That's a TR instruction, right? But when I search through our 40 years of assembler code, I see no uses of TR for such a purpose. I thinking this is because of difficulty in building the TR table. We'd need to have 256 bytes where every byte's value in in ascending sequence: 00 01 02 03 04 05 06 07 08 09 0A etc, right? Except for the byte at offset x'5C', which would have the value x'40'. Is there a slick way or a macro to build the TR table? Or do people just code a TRT loop instead, since it is easier to build a TRT table? What you want should be trivial: |TABLE DC 256AL1(*-TABLE) | ORG TABLE+C'*' | DC CL1' ' | ORG , -- Phoenix Software International Edward E. Jaffe Chief Technology Officer 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.
Generating a TR field
I want to replace all '*' with a space in a field. That's a TR instruction, right? But when I search through our 40 years of assembler code, I see no uses of TR for such a purpose. I thinking this is because of difficulty in building the TR table. We'd need to have 256 bytes where every byte's value in in ascending sequence: 00 01 02 03 04 05 06 07 08 09 0A etc, right? Except for the byte at offset x'5C', which would have the value x'40'. Is there a slick way or a macro to build the TR table? Or do people just code a TRT loop instead, since it is easier to build a TRT table?
