Reversed string macro

[Steve Smith]

Submitted for your consideration...

MACRO
&LABEL #REVSTR &STR
&ISTR SETC DEQUOTE('&STR')
&L SETA DCLEN('&ISTR')
.*
&A SETA &L
.LOOP AIF (&A LT 1).DONE
&OSTR SETC '&OSTR'.'&ISTR'(&A,1)
&A SETA &A-1
AGO .LOOP
.*
.DONE ANOP
DC C'&OSTR'
&LABEL EQU *-1,&L
MEND

E.G.:

3161 *
3162 #TAG #REVSTR 'IKJTCB'
3163+ DC C'BCTJKI'
3164+#TAG EQU *-1,6
3165 #DOG #REVSTR 'The quick brown fox jumped over the lazy dog.'
3166+ DC C'.god yzal eht revo depmuj xof nworb kciuq ehT'
3167+#DOG EQU *-1,45

--
sas

[zMan]

TIL: In a proportional font, an assembler macro looks like modern poetry.

--
zMan -- "I've got a mainframe and I'm not afraid to use it"

[João Reginato]

Better could be
&LABEL DC C'&OSTR'

[rob...@dodo.com.au]

Have you tried MVCIN ?

[Seymour J Metz]

No. From PoOps: "The second-operand address designates the rightmost byte of the second operand.".


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of João Reginato [jb.re...@GMAIL.COM]
Sent: Friday, October 23, 2020 12:34 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Reversed string macro

[Seymour J Metz]

MVCIN is not a BIF in HLASM. Don't confuse what is available at run time with what is available at assembly time.

Is there an RFE for a REVERSE BIF in HLASM? Is there a PL/I compile time REVERSE function?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of rob...@DODO.COM.AU [rob...@DODO.COM.AU]
Sent: Friday, October 23, 2020 12:57 AM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Reversed string macro

[Steve Smith]

The purpose, as most know, is to generate the source for an MVCIN
instruction, which was recently discussed (maybe on IBM-MAIN?).

Turns out, I found a bug in it. It drops characters when && or '' are in
the string. So replace " &A SETA &L" with "&A SETA K'&ISTR ".

From the corrected version:
1954 TAMU #REVSTR 'Texas
A&&M University'
000012A7 A8A389A29985A589 1955+ DC
C'ytisrevinU M&&A saxeT'
000012AF 95E440D450C140A2

000012B7 81A785E3

000012BA 00000014 1956+TAMU EQU *-1,20

DCLEN is correct for the EQU length. N.B. In case it's not clear, the EQU
defines the address of the end of the string, with a length attribute. It
might be handy for say,

MVCIN @PRTHDR,TAMU
...
@PRTHDR DS CL(L'TAMU)

sas

[João Reginato]

ok if PoOps is the target


-----Mensagem original-----
De: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> Em nome
de Seymour J Metz
Enviada em: sexta-feira, 23 de outubro de 2020 09:04
Para: ASSEMBL...@LISTSERV.UGA.EDU
Assunto: Re: Reversed string macro

[rob...@dodo.com.au]

On 2020-10-23 23:06, Seymour J Metz wrote:
> MVCIN is not a BIF in HLASM.

MVCIN is an instruction.

> Don't confuse what is available at run
> time with what is available at assembly time.
>
> Is there an RFE for a REVERSE BIF in HLASM? Is there a PL/I compile
> time REVERSE function?
>

[Tony Thigpen]

Robin,

The discussion (which I started) is about using a macro to reverse data
in the assembly so that it can later be used by a MVCIN to set an
eyecatcher.

You have apparently not read all the posts.

Tony Thigpen

rob...@DODO.COM.AU wrote on 10/23/20 10:18 AM:

[Seymour J Metz]

> MVCIN is an instruction.

Whoosh!

The macro generates an inverted DC; it does not generate code to invert text during execution. MVCIN, like any z instyruction, is irrelevant.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of rob...@DODO.COM.AU [rob...@DODO.COM.AU]

Sent: Friday, October 23, 2020 10:18 AM

[Charles Mills]

Basically, MVCIN "undoes" what this macro does. This macro takes "Robin" as
input and generates "niboR" as output. MVCIN takes that as input and
produces "Robin" as output.

Charles

[Charles Mills]

Can you code an address expression with a literal? Is MVCIN TARGET,='Foo'+2 (or 2+='Foo', or some equivalent) valid? If so, you could embed your logic in an executable SETEYE macro that would take SETEYE TARGET,'EYECATCH' and generate MVCIN TARGET,='HCTACEYE'+7

You could certainly do it generating the constant in-line, but that is a cache no-no. Of course, if it only executes once per run, who cares?

Charles

[Keith Moe]

How about this:

00256A E801 8011 C133 00011 0263B 7340 MVCIN NDX$CEI+1,=C'ab'+L'=C'ab'-1

00263A 8182 7437 =C'ab'
000010 20098+NDX$CEI DS H

Keith Moe
BMC Software, Inc.

[Paul Gilmartin]

On 2020-10-23, at 16:32:30, Charles Mills wrote:
>
> Can you code an address expression with a literal? Is MVCIN TARGET,='Foo'+2 (or 2+='Foo', or some equivalent) valid? If so, you could embed your logic in an executable SETEYE macro that would take SETEYE TARGET,'EYECATCH' and generate MVCIN TARGET,='HCTACEYE'+7
>

I believe it must be:
MVCIN TARGET,=C'Foo'+2

What's dismaying is that Assembler prohibits for no good reason:
DC S(=C'Foo'+2)
... with equivalent base-displacement resolution.

> You could certainly do it generating the constant in-line, but that is a cache no-no. Of course, if it only executes once per run, who cares?
>

Agreed.

-- gil

[Charles Mills]

Yeah, I forgot the C between the = and the '.

Good to know it works.

I have often coded an eyecatcher compare to make sure I had found the
control block I expected. Too bad there is not a CLCIN instruction. The OC
of 40's that someone suggested won't work very well in this situation either
(not without an intermediate work area).

So here's a new pointless assembler problem. What is the best way to compare
for a good eyecatcher without an in-memory constant that looks just like the
eyecatcher?

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Friday, October 23, 2020 4:24 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Reversed string macro

[Robin Vowels]

----- Original Message -----
From: "Tony Thigpen" <to...@VSE2PDF.COM>
To: <ASSEMBL...@LISTSERV.UGA.EDU>
Sent: Saturday, October 24, 2020 1:55 AM
Subject: Re: Reversed string macro

> Robin,

> The discussion (which I started)

The "discussion" was started by Steve Smith (also confirmed from the below letter).

> is about using a macro to reverse data
> in the assembly so that it can later be used by a MVCIN to set an
> eyecatcher.

Using MVCIN was not mentioned as a purpose.

Your "purpose" seems pointless, anyway.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Tony Thigpen]

Robin,

I did start the discussion.

See email from 10/20/20, 4:06 PM (EST) with the subject: "Another Macro
question"

The fact that Steve changed the subject, rightly so, when he posted a
macro sample that addressed the original thread, does not mean that the
discussion started then.

As I said, you are missing the original information that started the
discussion.

And, a simple search for any recent posts by me would have quickly
validated my statement that I had started the discussion.

Tony Thigpen

Robin Vowels wrote on 10/24/20 1:32 AM:

[Jonathan Scott]

I do hope no-one is taking this thread too seriously.

The use of MVCIN to set a data area eyecatcher is incredibly
inefficient.

If you really think that there it is important to ensure that
data area eyecatchers aren't found in the code which creates
them, you can copy the convention used internally by much of
CICS, which is to move in a prefix character followed by the
rest, so the prefix character is normally set with MVI and the
rest with MVC.

I've just compared a MVI, MVC sequence with a MVCIN instruction
and it was more than 10 times faster on this machine.

Jonathan Scott, HLASM
IBM Hursley, UK

[Charles Mills]

There's another macro exercise. Given MYBLKHDR,'EYECATCH' to generate MVI
MYBLKHDR,C'E'/MVC MYBLKHDR+1(L'MYBLKHDR-1),=C'YECATCH'

An immediate instructions also "solves" my eyecatcher compare query,
lamenting the lack of "CLCIN."

CLI for the first character followed by a CLC for the remainder would have
the advantage that probably more than 9 times out of 10 the CLI would be
sufficient.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]

On Behalf Of Jonathan Scott
Sent: Saturday, October 24, 2020 8:13 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Reversed string macro

[Paul Gilmartin]

On 2020-10-24, at 13:48:42, Charles Mills wrote:
>
> There's another macro exercise. Given MYBLKHDR,'EYECATCH' to generate MVI
> MYBLKHDR,C'E'/MVC MYBLKHDR+1(L'MYBLKHDR-1),=C'YECATCH'
>
> An immediate instructions also "solves" my eyecatcher compare query,
> lamenting the lack of "CLCIN."
>

Yes.

> CLI for the first character followed by a CLC for the remainder would have
> the advantage that probably more than 9 times out of 10 the CLI would be
> sufficient.
>

I had imagined that the OP planned to search not with a program
but intereactively in a browser.

How likely are false positives? Are there any characters to avoid
perhaps because they might be likely in Packed decimal values.

> -----Original Message-----
> From: Jonathan Scott
> Sent: Saturday, October 24, 2020 8:13 AM
> ...
> The use of MVCIN to set a data area eyecatcher is incredibly
> inefficient.
>

But is the code path heavily traveled?

-- gil

[Tony Thigpen]

I kinda like the concept, but a lot of literals we use are just 4
characters, so it does not scale down easily.

One of the other thoughts mentioned was lower-case vs. upper-case. Maybe
a macro that accepts upper-case, but stores it as lower-case, then ORs
it with x40 when moving it:

TAGIT MY_TAG,ABCD
that generates:
MVC MY_TAG,=C'abcd'
OC MY_TAG,=C' '

I would have to set my editor a little different when viewing dumps, but
it may work better than the original MVCIN thought. (I normally use
"case mixed ignore" in XEDIT.)

Tony Thigpen

Paul Gilmartin wrote on 10/24/20 4:27 PM:

[Paul Gilmartin]

On 2020-10-24, at 15:06:32, Tony Thigpen wrote:
>
> I kinda like the concept, but a lot of literals we use are just 4 characters, so it does not scale down easily.
>

??? "scale"?

> One of the other thoughts mentioned was lower-case vs. upper-case. Maybe a macro that accepts upper-case, but stores it as lower-case, then ORs it with x40 when moving it:
>
> TAGIT MY_TAG,ABCD
> that generates:
> MVC MY_TAG,=C'abcd'
> OC MY_TAG,=C' '
>

Why bother? Enter it as C'abcd'. Easily enough done with "case mixed ignore".

> I would have to set my editor a little different when viewing dumps, but it may work better than the original MVCIN thought. (I normally use "case mixed ignore" in XEDIT.)
>

Has XEDIT nothing like ISPF's "find c'ABCD'" with does a case-sensitive
search regardless of the CAPS setting?

-- gil

[Charles Mills]

Why not? What's wrong with MVI/MVC for 3?

Given that it would involve no storage references beyond the target and
i-cache, I wonder if the fastest way to set four bytes, without the string
appearing in storage, might not be four sequential MVI's.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Tony Thigpen
Sent: Saturday, October 24, 2020 2:07 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Reversed string macro

[Mike Hochee]

You can also do it with two MVHHI instructions. (which I tend favor!)

Your question also seems to highlight the need for a store immediate that supports a 4 byte immediate value, if for no other reason than to complement the load logical immediate instructions.

I know the sky is not the limit here, but I could definitely find uses for 8 byte immediate values as well.

Mike

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Charles Mills
Sent: Saturday, October 24, 2020 5:24 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Reversed string macro

Caution! This message was sent from outside your organization.

[Tony Thigpen]

I was thinking that the MVI would be some sort of special character,
limiting the tag to just 3 unique characters. But now I understand it
better. My mistake.

Tony Thigpen

Charles Mills wrote on 10/24/20 5:23 PM:

[Keven Hall]

Would not L/ST be faster than 4-MVIs? Most every control-block I’ve seen bearing an eye-catcher is Fullword aligned in storage which makes for optimal execution.

Keven


> On Oct 24, 2020, at 16:57, Tony Thigpen <to...@vse2pdf.com> wrote:
>
> I was thinking that the MVI would be some sort of special character, limiting the tag to just 3 unique characters. But now I understand it better. My mistake.

[Tony Thigpen]

Gil,

It is a personal preference of mine to never edit an assembler source
with lower-case turned on. I just do not like mixed case assembler source.

While Xedit has a lot more flexibility, especially when it comes to
locating something in the file, it always respects the SET CASE options
or 'respect' or 'ignore':

Tony Thigpen

Paul Gilmartin wrote on 10/24/20 5:22 PM:

[Tony Thigpen]

He was talking 1 mvi for the first character of the tag, then one MVC
for the following characters. Not multiple MVIs.
MVI MYTAG,C'A'
MVC MYTAG+1(3),=C'BCD'

Tony Thigpen

Keven Hall wrote on 10/24/20 6:00 PM:

[Mike Hochee]

Forgot to mention... use of 8 byte immediate values implies support for them at the EQU level as well...

CTLBNAME EQU C'CTLBNAME' (which is currently limited to just 4 bytes)

One of the few types of instructions which kind of supports an 8 byte immediate value are the compare logical immediates, but only if you're okay with the high order 32bits of the immediate value being zero.

FWIW, I dislike use of lower case for instruction mnemonics and operands, but have grown to appreciate LC for struc labels and comments.

Mike

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Mike Hochee
Sent: Saturday, October 24, 2020 5:55 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Reversed string macro

Warning! This is a fake (spoofed) message. DO NOT TRUST!

[Paul Gilmartin]

On 2020-10-24, at 15:06:32, Tony Thigpen wrote:
>

> ... (I normally use "case mixed ignore" in XEDIT.)

On 2020-10-24, at 16:05:59, Tony Thigpen wrote:
>
> It is a personal preference of mine to never edit an assembler source with lower-case turned on. I just do not like mixed case assembler source.
>

Taken together, those two statements imply that you don't
normally edit assembler source with XEDIT.

I have always used MIXED/CAPS OFF, even before a case-insensitive
assembler was available. I like to type comments in mixed case
to set them off visually from code.

-- gil

[Seymour J Metz]

It is possible to write XEDIT macros to support mixed case comments with upper case labels and opcodes.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [00000014e0e4a59...@LISTSERV.UGA.EDU]
Sent: Saturday, October 24, 2020 8:15 PM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Reversed string macro

[Tony Thigpen]

Correct, I typed it wrong. "case upper ignore" is what I use.
(It's been a long week....)

Tony Thigpen

Paul Gilmartin wrote on 10/24/20 8:15 PM:

[Paul Gilmartin]

On 2020-10-24, at 18:35:32, Seymour J Metz wrote:
>
> It is possible to write XEDIT macros to support mixed case comments with upper case labels and opcodes.
>

Hmmm... I could imagine:

Treat any token starting in Col. 1 as CASE UPPER.
Treat the first token following a blank on a non-continuation line as CASE UPPER.
Treat '*' lines and everything else as CASE MIXED.

I wasted a lot of time customizing XEDIT with macros. I never got
as far as that one.

-- gil

[Tony Thigpen]

I have a lot of xedit macros, including some post edit reformatters, but
I never thought of that one. But, I don't think I will spend the time on
it since I rather just switch to mixed case for the few times I really,
really need it.

Tony Thigpen

Seymour J Metz wrote on 10/24/20 8:35 PM:

[Paul Gilmartin]

On 2020-10-24, at 19:39:43, Tony Thigpen wrote:
>
> I have a lot of xedit macros, including some post edit reformatters, but I never thought of that one. But, I don't think I will spend the time on it since I rather just switch to mixed case for the few times I really, really need it.
>

It's infuriating to make a tiny change and see the entire
remainder of the line flip to UPPER. Will Undo fix that?

Design shortcoming. There should be a Modified Data Tag
for each character, not one for the entire line, so only
modified characters could be converted to upper.

-- gil

[Phil Smith III]

Gil wrote:

>It's infuriating to make a tiny change and see the entire

>remainder of the line flip to UPPER. Will Undo fix that?

Long ago and far away (verging on 40 years), I wrote an AUTOCASE mod for XEDIT. When CASE was UPPER, it would examine the line
before uppercasing and, if there was a mixture of upper and lowercase, NOT uppercase. So you could type:



label ds 0h

<hit ENTER, it uppercases>



But if you changed this line:

MVC WHATEVER,SOMETHING Move something to whatever

(yes, that's a horrible comment) it would NOT uppercase. If you also did not have ENTER force the cursor to the command line, then
you could enter the code, hit ENTER, get your uppercased code, then go on and write the comment. That was pretty useful for coding
assembler.

>Design shortcoming. There should be a Modified Data Tag

>for each character, not one for the entire line, so only

>modified characters could be converted to upper.

Yeah, but the only way to really do this is with extended attributes (SA), and when XEDIT was written, those were either very new
and rare or didn't exist yet. My beloved 3278-4 certainly wouldn't support them, and that was the model terminal at the time.
Optimizing rewrite of such data is also a pain, though I found a trick: there's an unused bit in the attribute byte, so you can use
that as an MDT in the internal representation. You just have to make sure to clear it before the write, or you'll X Clock. Still,
not sure this extra processing would have been tolerable on early-80s machines, where every instruction was still valuable.
Nowadays, of course, no problem!



...phsiii