ASMA034E

[ess...@juno.com]

hello

I know this topic has been discussed before..
Im on a Z/OS 1.7 system with HLASM R5.0
...
Im trying to maintain the concept of "Baseless Code" in some programs, I keep running into some macros on Z/os 1.7 that use BAL R15,*+20
.
.
And as such i receive message
** ASMA034E Operand *+20 beyond active USING range by 185 bytes
** ASMA435I Record 124 in SYS1.MACLIB(IHBINNRB) on volume: S7RES1
.
.
I could move the routine to another location in this module, and that would avoid the ASMA034E. Is there a recommended technique to use where I could convert the BAL instruction in the macro to another branch instruction ?
.
.
Paul D'Angelo

[McNeill,Cliff]

I am away on vacation. I will be returning Monday April 21, 2014. If this is an emergency please call Susan Kincaid at (713) 745-9311. Or you can page me at (713) 404-9779.

[Wojtczak Arkadiusz]

Dzień dobry,
do 18 kwietnia przebywam poza biurem. Poczta nie jest przekierowywana.
W sprawach pilnych proszę o kontakt z Krzysztofem Szubą.
Pozdrawiam,
Arkadiusz Wojtczak

[Wolfgang Rupprath]

Ich bin bis einschließlich Freitag, den 25.4.2014 in Urlaub.

Den Produktsupport der FSP können Sie unter der Mail-Adresse support(at)fsp-gmbh.com oder telefonisch unter der Rufnummer 02203 / 371 000 0 erreichen.

Mit freundlichen Grüßen
Wolfgang Rupprath
FSP GmbH

[DAL POS Raphael]

Je suis actuellement en congés et je ne serais de retour que le 2014/04/28. Durant cette période merci de contacter DSI-PROD-SYSTEME-CENTRAUX. Cordialement.
Cette notification ne vous sera adressée qu'une seule fois.
I'm currently out of the office and will not return until 2014/04/28. In the meanwhile, please send all your requests to DSI-PROD-SYSTEME-CENTRAUX. Best regards. You will receive this notification only once. Sono assente per ferie.Sarò di ritorno il 2014/04/28. Per eventuali richieste urgenti, Vi prego di contattare DSI-PROD-SYSTEME-CENTRAUX. Cercherò di rispondervi o richiamarvi appena possibile. Grazie. Cordiali saluti.
Ich werde ab 2014/04/18 nicht im Büro sein. Ich kehre zurück am 2014/04/28.

[Bernd Oppolzer]

You did use the

SYSSTATE ARCHLVL=2
SYSSTATE OSREL=ZOSV1R8

calls, did you?

Maybe OSREL=ZOSV1R7 in your case ...

For me, most of the issues with IBM macros disappeared, when I used this
calls ...

I had some other issues with home grown macros which I couldn't fix because
the responsibility was in another department (sigh!), so I fixed this by
establishing
temporary base registers around the macro call... or I moved the macro
call to
another place, where I have base register addressibility (the first 4 k
of a
subroutine).

Kind regards

Bernd

[Robert A. Rosenberg]

I think that there is a SYS????? macro you can put at the start of
your code that tells macros like IHBINNRB to use baseless branches in
lieu of BAL. Look at the IHBINNRB macro and see if there is an AIF to
cause it use an alternate instruction.

[ess...@juno.com]

Yes I forgot about SYSSTATE ...

---------- Original Message ----------
From: Bernd Oppolzer <bernd.o...@t-online.de>
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: ASMA034E
Date: Sat, 19 Apr 2014 21:51:16 +0200

You did use the

SYSSTATE ARCHLVL=2
SYSSTATE OSREL=ZOSV1R8

calls, did you?

Maybe OSREL=ZOSV1R7 in your case ...

For me, most of the issues with IBM macros disappeared, when I used this
calls ...

I had some other issues with home grown macros which I couldn't fix because
the responsibility was in another department (sigh!), so I fixed this by
establishing
temporary base registers around the macro call... or I moved the macro
call to
another place, where I have base register addressibility (the first 4 k
of a
subroutine).

Kind regards

Bernd



Am 19.04.2014 20:35, schrieb ess...@juno.com:

[Binyamin Dissen]

Copy IEABRC

On Sat, 19 Apr 2014 18:35:49 GMT "ess...@juno.com" <ess...@juno.com> wrote:

:>hello

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[Bernd Oppolzer]

In fact, when the IBM macro generates BAL,
the missing SYSSTATE is maybe not the problem.

SYSSTATE is needed if you get such things as LA R1,*+20
because in this case IEABRC(X) doesn't help.

I have in my startup macro:

SYSSTATE ARCHLVL=2
SYSSTATE OSREL=ZOSV1R8
IEABRCX DEFINE

SYSSTATE makes sure, that the IBM macros don't use LA etc.
to get the addresses of inline parameter lists (but BAL instead, for
example)

and IEABRCX takes care that the BAL is replaced by the proper relative
branch.

Thank you, regards

Bernd

[Martin Truebner]

SYSSTATE has been mentioned

IEABRC(X) has been mentioned

moving it has been mentioned

temp base has been mentioned

-----

here is a new one

BAL OPSYN JAS

in the very front to replace the BAL by JAS "on the fly"

--
Martin

Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de

[Steve Smith]

I've found that SYSSTATE ARCHLVL=2 takes care of most everything from IBM,
with no need for IEABRC, or other OPSYNs.

--
sas

[Farley, Peter x23353]

Some macros, like CALL, require and support additional parameters to replace non-relative branch instructions. CALL defaults to BALR, but you can replace it with LINKINST=BASR.

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Steve Smith
Sent: Wednesday, April 23, 2014 1:37 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: ASMA034E

I've found that SYSSTATE ARCHLVL=2 takes care of most everything from IBM,
with no need for IEABRC, or other OPSYNs.


On Sun, Apr 20, 2014 at 3:02 AM, Martin Truebner <Mar...@pi-sysprog.de>wrote:

> SYSSTATE has been mentioned
>
> IEABRC(X) has been mentioned
>
> moving it has been mentioned
>
> temp base has been mentioned
>
> -----
>
> here is a new one
>
> BAL OPSYN JAS
>
> in the very front to replace the BAL by JAS "on the fly"
>
--

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.

[Peter Relson]

>BAL OPSYN JAS
>
>in the very front to replace the BAL by JAS "on the fly"

This is insufficient in the general case which is why IEABRC(X) is more
involved than OPSYN.
BAL 0(14)
has no JAS analog. Thus IEABRC(X) does not translate that invocation to
JAS.

Of course for many modules the OPSYN would work fine. But why you'd not
cover all the cases by copying IEABRC or using IEABRCX, I don't know.

Peter Relson
z/OS Core Technology Design

[John P Kalinich]

I wrote a small subroutine to right justify a field. I started scanning
left at the end of the field and counted spaces until I found a non-blank
character. Then I subtracted the number of blanks from the starting
address of the field (which was prefixed with spaces) and then moved the
data from that address to a new field. Is there an easier way to do this?

Regards,
John K

[DASDBILL2]

As always, the answer is it depends -- on what you mean by easier.
1.  You have already finished the subroutine.  To do it another way would mean more work, which is not easier.
2.  You could probably do it in APL with only one instruction, but the result would be unintelligible gibberish to everyone except an APL expert.
3.  What is easier for someone else to maintain your subroutine, to me, would imply making the code as intuitively obvious and straightforward as possible.  If this is your definition of easier, then you are all done.
4. There could well be a new exotic instruction in the z/OS architecture that I haven't learned about yet that would reduce some of your logic by one or more instructions, but the result might be less intuitively obvious looking to someone else (similar to 3 above).
5.  There might be another way to code this logic that would execute faster than your code now, but it might also be less intuitively obvious looking to someone else (see 3 above some more).
6.  IBM could introduce a new instruction next year that would replace much of your logic, but ... (see 3 above).
 
You wrote the code the way I would write it, except that I might not have counted the spaces while scanning left, in which case I would subtract the address of the right-most non-blank from the address of  the end of the field to compute the number of spaces.  This would probably execute faster than your technique.  But "faster" is also relative -- how many million times per second will your subroutine run?  How much will the savings in execution time be worth compared to your extra time to reinvent an already working wheel?
 
Good job.  Stop while you are ahead.
 
Another thing to remember is that no matter how good, excellent, and optimal your code is, someone else might still be able to tweak it slightly so that it is even better.  Back in the late 1960s some colleagues of mine and I challenged each other to code a text-editing subroutine such that the resulting code fit in the smallest number of  bytes with no regard for how many instructions were executed, if the code was self-modifying or not, etc.  The various results we all produced were interesting, convoluted, and surprisingly innovative.
 
Bill Fairchild

----- Original Message -----

[John Gilmore]

If your routine is to be used heavily there is a much faster way to do
left justifications. It is to use a TRTE with a 256-byte table that
defines only a blank, x'40', as a licit character. This approach
yields the zero-origin offset of the leftmost non-blank directly.

If I were writing such a routine, as I did long ago, I would also give
it an additional entry point for right justification, which can [now]
be accomplished using the same approach [and the same table] but using
a TRTRE instead of a TRTE.

I agree 'philosophically' with most of what Bill wrote; but
single-character-by-single-character operations on strings are, I
think, not just tedious but ugly where better approaches are
available.

John Gilmore, Ashland, MA 01721 - USA

[Blaicher, Christopher Y.]

John,
Because of the nature of TRT, TRTE and TRTRE a single byte CLI loop can be faster to much faster, or at least they have been in the past. I don't think they have changed the underlying hardware process in the EC12, but I have been wrong in the past. I once read that if you were looking for up to 3 different characters in a string, the open code method will beat any of those three instructions.

The problem with TRT is it validates the whole TRT table before it starts to do the TRT. I believe TRTE and TRTRE also suffer from that, but also they are milli-coded, or is it micro-coded, which incurs a non-trivial amount of instruction startup and termination time. The overheads are similar to MVCL compared to MVC used in a loop. A loop of MVC's will reduce the CPU time of a routine until you get to close to moving 32K at a time. If you are moving more than 32K at a time, then MVCL can win.

As you say, the single CLI loop is ugly, but it can be much faster. I am writing code right now that uses the TRT and TRTRE instructions, but that is for exception error processing, not record level or sub-record level processing so speed was not my primary concern.

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260 | M: 512-627-3803
E: cbla...@syncsort.com

[Michael Harding]

If "this is your field " I wouldn't want to right-justify it based on
finding the first blank with TRT/R/E.

--
Mike Harding
z/VM System Support

/sp


IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> wrote on
05/15/2014 12:00:52 PM:

[Blaicher, Christopher Y.]

Using TRTRE makes it very simple. Build a TRT table with all bytes non-zero except the C' ' byte and execute the instruction. After the instruction R1 will point at the 'D' in field. TRTRE works right to left rather than left to right.



TRTTABLE DC 256XL1'04'

ORG TRTTABLE+C' '

DC XL1'00'

ORG ,

Chris Blaicher

Principal Software Engineer, Software Development

Syncsort Incorporated

50 Tice Boulevard, Woodcliff Lake, NJ 07677

P: 201-930-8260 | M: 512-627-3803

E: cbla...@syncsort.com



-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Michael Harding
Sent: Thursday, May 15, 2014 3:19 PM
To: MVS List Server 2
Subject: Re: Right Justification Subroutine

If "this is your field " I wouldn't want to right-justify it based on

finding the first blank with TRT/R/E.



--

Mike Harding

z/VM System Support



/sp

IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu<mailto:ASSEMBL...@listserv.uga.edu>> wrote on

05/15/2014 12:00:52 PM:

> From: "Blaicher, Christopher Y." <cbla...@syncsort.com<mailto:cbla...@syncsort.com>>

> To: ASSEMBL...@listserv.uga.edu<mailto:ASSEMBL...@listserv.uga.edu>

> Date: 05/15/2014 12:07 PM

> Subject: Re: Right Justification Subroutine Sent by: IBM Mainframe

> Assembler List <ASSEMBL...@listserv.uga.edu<mailto:ASSEMBL...@listserv.uga.edu>>

>

> John,

> Because of the nature of TRT, TRTE and TRTRE a single byte CLI loop

> can be faster to much faster, or at least they have been in the past.

> I don't think they have changed the underlying hardware process in the

> EC12, but I have been wrong in the past. I once read that if you were

> looking for up to 3 different characters in a string, the open code

> method will beat any of those three instructions.

>

> The problem with TRT is it validates the whole TRT table before it

> starts to do the TRT. I believe TRTE and TRTRE also suffer from that,

> but also they are milli-coded, or is it micro-coded, which incurs a

> non-trivial amount of instruction startup and termination time. The

> overheads are similar to MVCL compared to MVC used in a loop. A loop

> of MVC's will reduce the CPU time of a routine until you get to close

> to moving 32K at a time. If you are moving more than 32K at a time,

> then MVCL can win.

>

> As you say, the single CLI loop is ugly, but it can be much faster.

> I am writing code right now that uses the TRT and TRTRE instructions,

> but that is for exception error processing, not record level or

> sub-record level processing so speed was not my primary concern.

>

> Chris Blaicher

> Principal Software Engineer, Software Development Syncsort

> Incorporated

> 50 Tice Boulevard, Woodcliff Lake, NJ 07677

> P: 201-930-8260 | M: 512-627-3803

> E: cbla...@syncsort.com<mailto:cbla...@syncsort.com>

[Hardee, Chuck]

Won't the TRTRE stop at the first blank in the field?
If so, it will stop at the right end, not at the "d".
Maybe I've misread the pOps.

[John Gilmore]

Mike,

People are free to use right justify and left justify in different
ways. I covered the cases of eliminating leftmost and rightmost
blanks using respectiively TRTE and TRTRE.

Chris,

I have some different numbers; but if the thrust of what you are
saying is that the behavior of millicoded instructions is
model-dependent, I agree strongly. Worse, it appears to be [calendar]
time-dependent. IBM apparently fiddles with the millicode
implementations of these instructions on a continuing basis and in
ways that affect their relative and absolute timings.

Moreover, cache effects, mostly deleterious ones, are more significant
for loops than for single instructions. On the other hand your
situation with SYNCSORT may require you to be very largely
model-independent in your choices of instruction sequences.

I do not tend to avoid millicoded instructions because they are
millicoded. Their deficiencies have, I think, been exaggerated. They
get better over time, and they make use of facilities/instructions
that we cannot use. They are not, that is, just stored code
sequences.

[Tom Marchant]

On Thu, 15 May 2014 12:49:13 -0700, Hardee, Chuck wrote:

>Won't the TRTRE stop at the first blank in the field?
>If so, it will stop at the right end, not at the "d".
>Maybe I've misread the pOps.

It depends upon how you code your translate table.

--
Tom Marchant

[Hardee, Chuck]

Unless I misunderstood, it was stated that it was coded with only 1 non-zero entry, the space.

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
CCG Information Technology
Thermo Fisher Scientific
300 Industry Drive
Pittsburgh, PA 15275
Direct: 724-517-2633
FAX: 412-490-9230
Chuck....@ThermoFisher.com

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant
Sent: Thursday, May 15, 2014 4:58 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Right Justification Subroutine

[John Gilmore]

As I thought, indeed still think, I had made clear, it will stop on
the first, leftmost or rightmost, non-blank.

[Gerhard Postpischil]

As Bill said, there are different ways of accomplishing the same thing.
For example, you could use MVCIN to a work field, followed by TRT for a
non-blank. It takes more storage and registers, and may not be faster
depending on the field length. I would consider it easier to maintain.

Gerhard Postpischil
Bradford, Vermont

[Tony Harminc]

On 15 May 2014 15:00, Blaicher, Christopher Y. <cbla...@syncsort.com> wrote:
> The problem with TRT is it validates the whole TRT table before it starts to do the TRT.

I think you are speaking of access exceptions for the table (the
second operand), which because of the instruction definition can
require an extraordinary amount of setup, and perhaps a trial
execution. Access failures are not to be recognized for table bytes
not actually referenced, and of course this depends on the content of
the first operand. The presumably worst case is when the notionally
256-byte table straddles a page boundary. EDIT and EDMK can also incur
this problem.

> I believe TRTE and TRTRE also suffer from that, but also they are milli-coded, or is it micro-coded, which incurs a
> non-trivial amount of instruction startup and termination time.

TRTE and TRTRE do not suffer from the TRT table access problem,
because "Access exceptions for any byte of the function-code table
specified by general register 1 may be recognized, even if not all
bytes are used".

> The overheads are similar to MVCL compared to MVC used in a loop. A loop of MVC's will reduce the CPU time of
> a routine until you get to close to moving 32K at a time. If you are moving more than 32K at a time, then MVCL
> can win.

I use MVCL a lot even for very small moves where the length is not
known at assembly time. But I know my environment and its performance
requirements, and often judge the relative elegance, generality, and
programmer-readability of such an instruction to override what small
performance gain there might be to multipathing and/or loops.

Tony H.

[John P Kalinich]

Thanks to all that replied. I was not aware of the TRTR instruction.
Using TRTR, I was able to code the routine in less than half the
instructions used by the loop method. And performance was better although
it does not matter in my case.

Regards,
John K

[Steve Comstock]

Part of the instructions introduced with the z990

http://www.trainersfriend.com/Assembler_courses/C500descrpt.htm

-Steve Comstock

[DASDBILL2]

Back around 1966, when I first got into Assembler language programming and S/360 innards, I read the entire Principles of Operation book.  I read the entire book again about once every ten years.  I have not had, taken, or made the time to read this whole book for 15 or more years, but I did closely read chapters 13-17 of it about eight years ago when I was building code to simulate the I/O subsystem hardware.  There are many, many "new" instructions which I do not yet know about, such as TRTR.  I learned all about 64-bit architecture, addressing, and the "grande" instructions in 2000 when I had to know about these things for my job.  I would really like to read the entire PoO again some time.  Now that I am 70 years old, I would also like to do many other things with my remaining years when my eyes and mind still work well.  If I can build code to solve a problem using ancient instructions, that is usually good enough for me and my manager.  Elegance is nice, but very time-consuming.  OTOH, once I learn about newer instructions or ways of doing things, I try to use them in future code that I write.
Bill Fairchild
Nolensville, TN

----- Original Message -----

From: "Steve Comstock" <st...@trainersfriend.com>
To: ASSEMBL...@LISTSERV.UGA.EDU
Sent: Friday, May 16, 2014 11:09:34 AM
Subject: Re: Right Justification Subroutine

[John Gilmore]

There are some red threads, patterns in the additions that have
been/are being made to the z/Architecture instruction set.

Text in most modern European languages, and notably in English, is
ordinarily read and processed in left-to-right sequence. Other languages,
among modern ones notably Arabic, Hebrew, and Farsi, process and read
text in right-to-left sequence. Still other languages, chiefly
oriental ones, are more relaxed. Text may be arranged in
top-to-bottom, bottom-to-top (more rarely), or even one of the eight
variants of boustrophedon.

An interesting subset of these new instructions occur in pair with
older ones. We have

o TRT, TRTR

o ST, STRV

o MVC, MCVIN

in which the traditional instruction operates from left to right, low
to high storage address, and the new one operates from right to left.

Confronted with a right-to-left processing requirement, one should now
look for an instruction that will facilitate it, make methods that
would be usable to meet the analogous left-to-right one usable for it
too.

Another reason for familiarizing oneself with the new instructions is
that they may alert one to their serendipitous uses. We have been
talking about eliminating rightmost blanks using TRTR. Other examples
abound. CKSM typically computes a message-text checksum, but it also
caslculates the sum required for hashing varying-length character
strings using von Neumann's division-method hashing scheme. (It does
not do the division by a suitable small prime to obtain a hash value
proper, but that is the easy part.)

I encourage my students to browse in what I call the PrOp and to do
some experimental coding using the new instructions they find in it.
It is not a time-wasting activity!

[Robin Vowels]

From: "Tony Harminc" <to...@harminc.com>
Sent: Friday, May 16, 2014 8:44 AM

> I use MVCL a lot even for very small moves where the length is not
> known at assembly time. But I know my environment and its performance
> requirements, and often judge the relative elegance, generality, and
> programmer-readability of such an instruction to override what small
> performance gain there might be to multipathing and/or loops.

Sounds like overkill.
MVC with EX would be simpler.

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[Robin Vowels]

From: "Tony Harminc" <to...@harminc.com>
To: <ASSEMBL...@LISTSERV.UGA.EDU>

Sent: Friday, May 16, 2014 8:44 AM

> On 15 May 2014 15:00, Blaicher, Christopher Y. <cbla...@syncsort.com> wrote:
>> The problem with TRT is it validates the whole TRT table before it starts to do the TRT.
>
> I think you are speaking of access exceptions for the table (the
> second operand), which because of the instruction definition can
> require an extraordinary amount of setup, and perhaps a trial
> execution. Access failures are not to be recognized for table bytes
> not actually referenced, and of course this depends on the content of
> the first operand. The presumably worst case is when the notionally
> 256-byte table straddles a page boundary. EDIT and EDMK can also incur
> this problem.

If it does, wouldn't that also apply to all SS instructions, decimal instructions,
LM, STM etc?

[Ed Jaffe]

On 5/20/2014 8:44 PM, Robin Vowels wrote:
>
>> I use MVCL a lot even for very small moves where the length is not
>> known at assembly time. But I know my environment and its performance
>> requirements, and often judge the relative elegance, generality, and
>> programmer-readability of such an instruction to override what small
>> performance gain there might be to multipathing and/or loops.
>
> Sounds like overkill.
> MVC with EX would be simpler.

Not if you want padding.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

[Robin Vowels]

From: "Ed Jaffe" <edj...@phoenixsoftware.com>
Sent: Wednesday, May 21, 2014 2:52 PM

> On 5/20/2014 8:44 PM, Robin Vowels wrote:
>>
>>> I use MVCL a lot even for very small moves where the length is not
>>> known at assembly time. But I know my environment and its performance
>>> requirements, and often judge the relative elegance, generality, and
>>> programmer-readability of such an instruction to override what small
>>> performance gain there might be to multipathing and/or loops.
>>
>> Sounds like overkill.
>> MVC with EX would be simpler.
>
> Not if you want padding.

You didn't mention padding. Only small moves.

But even when padding is required, you can move the padding byte into the
destination area first.

[Rob van der Heij]

On 21 May 2014 07:34, Robin Vowels <rob...@dodo.com.au> wrote:

> From: "Ed Jaffe" <edj...@phoenixsoftware.com>
> Sent: Wednesday, May 21, 2014 2:52 PM
>
>
>
> On 5/20/2014 8:44 PM, Robin Vowels wrote:
>>
>>>
>>> I use MVCL a lot even for very small moves where the length is not
>>>> known at assembly time. But I know my environment and its performance
>>>> requirements, and often judge the relative elegance, generality, and
>>>> programmer-readability of such an instruction to override what small
>>>> performance gain there might be to multipathing and/or loops.
>>>>
>>>
>>> Sounds like overkill.
>>> MVC with EX would be simpler.
>>>
>>
>> Not if you want padding.
>>
>
> You didn't mention padding. Only small moves.
>
> But even when padding is required, you can move the padding byte into the
> destination area first.
>

At last resort one looks at the alternatives. The code I inherited has lots
of EX MVC (into static areas near the code even) but the area is too
crowded that I dare to free up the 4 right registers and change it.

Recently for some new code doing memory allocations, I was very pleased
with a MVCL. Rather elegant to have one instruction that copies the
prepared header into the block and wipes the payload with padding.Reading
the Principles of Operation last night, I noticed it states that some
models may be very good in doing MVCL. But probably also in MVC overlaps by
one byte, maybe even EX of those...

Rob

[Gerhard Postpischil]

On 5/20/2014 11:44 PM, Robin Vowels wrote:
> Sounds like overkill.
> MVC with EX would be simpler.

It depends very much on the requirement. For example, building a longer
string from several different sources; MVCL sets the destination address
and residual length after completion, allowing for simple chaining of
multiple moves. While EX/MVC can accomplish the same thing, they require
a little more arithmetic.

Gerhard Postpischil
Bradford, Vermont

[Robin Vowels]

From: "Gerhard Postpischil" <gerh...@charter.net>
Sent: Wednesday, May 21, 2014 8:38 AM

Only a BCTR.

It all can be handled trivially by a macro.

However, for multiple moves to an area, MVCL might offer something better,
but not when the moves are not contiguous.

[John McKown]

I tend to use MVCL like Tony does. The reason that I tend to not like doing
a EX of an MVC is because the MVC needs to be out-of-line. (and is the MVC
in the i-cache or the d-cache?) Also, this requires a base register to
address the area containing the MVC. Which is generally not a problem,
because I would guess that the MVC would be in the "constants" area of the
program. But that moves the MVC far away from the EX instruction. Unless
you use LOCTR a lot to section up the program. Which can lead to novice
programmers getting confused. Yes, I know about the "new" EXRL to avoid the
need of a base register.

--
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

[Steve Hobson]

> I tend to use MVCL like Tony does. The reason that I tend to not like
doing
> a EX of an MVC is because the MVC needs to be out-of-line. (and is the
MVC
> in the i-cache or the d-cache?) Also, this requires a base register to
> address the area containing the MVC. Which is generally not a problem,
> because I would guess that the MVC would be in the "constants" area of
the
> program. But that moves the MVC far away from the EX instruction. Unless
> you use LOCTR a lot to section up the program. Which can lead to novice
> programmers getting confused. Yes, I know about the "new" EXRL to avoid
the
> need of a base register.

For many years I've used this style which I was taught be the legendary
Pete Roberts:

MVC TARGET(0),SOURCE
EX Rx,*-6

It at least addresses the far-away MVC problem and I imagine helps with
the ICACHE too.

PS. Don't try this with TR :)


Best regards, Steve Hobson
CICS Strategy, HLASM Development, Master Inventor
Hursley Laboratories, MP 189, Room A4126, UK
Tie: 246894 International: +44 1962 81 6894

Je me presse de rire de tout, de peur d'être obligé d'en pleurer

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[David Stokes]

Well, there's always the old trick

EXRL R2,*+6
MVC Field(0),Data

if that's a concern.

-----Ursprüngliche Nachricht-----
Von: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] Im Auftrag von John McKown
Gesendet: Mittwoch, 21. Mai 2014 13:26
An: ASSEMBL...@LISTSERV.UGA.EDU
Betreff: Re: MVCL (was: Right Justification Subroutine)

[John McKown]

On Wed, May 21, 2014 at 6:38 AM, Steve Hobson <steve_...@uk.ibm.com>wrote:


<snip>

>
> For many years I've used this style which I was taught be the legendary
> Pete Roberts:
>
> MVC TARGET(0),SOURCE
> EX Rx,*-6
>

I had read of that before. One "problem" is that it assumes that I have a
base register for code. I have basically abandoned code base register and
now use the R&I versions of instructions. Of course, I could use the EXRL.
Except that EXRL doesn't exist on my z9BC. This is the _last_ processor
that I am likely to ever work on because z/OS has been "sunsetted" here and
will disappear no later than March 2016. Guaranteed. I know how they are
doing it and it _will_ work. But I am forbidden to talk about it. No, the
company is not going out of business, though that would work.

Oh, anybody know of a z/OS sysprog opening in the DFW metro-mess area?
Would really like to move on (after 20+ years here), especially if the new
place uses z/VM and z/Linux as well. <drool/>

>
> It at least addresses the far-away MVC problem and I imagine helps with
> the ICACHE too.
>
> PS. Don't try this with TR :)
>
>
> Best regards, Steve Hobson
> CICS Strategy, HLASM Development, Master Inventor
>

[Binyamin Dissen]

On Wed, 21 May 2014 12:38:09 +0100 Steve Hobson <steve_...@uk.ibm.com>
wrote:

:>> I tend to use MVCL like Tony does. The reason that I tend to not like

:>doing
:>> a EX of an MVC is because the MVC needs to be out-of-line. (and is the
:>MVC
:>> in the i-cache or the d-cache?) Also, this requires a base register to
:>> address the area containing the MVC. Which is generally not a problem,
:>> because I would guess that the MVC would be in the "constants" area of
:>the
:>> program. But that moves the MVC far away from the EX instruction. Unless
:>> you use LOCTR a lot to section up the program. Which can lead to novice
:>> programmers getting confused. Yes, I know about the "new" EXRL to avoid
:>the
:>> need of a base register.

:>For many years I've used this style which I was taught be the legendary
:>Pete Roberts:

:> MVC TARGET(0),SOURCE
:> EX Rx,*-6

:>It at least addresses the far-away MVC problem and I imagine helps with
:>the ICACHE too.

Requires a code base register.

I wrote an @EX macro which places the target instruction (via LOCTR) in the
data area. As the instruction is not reexecuted, valid for the various TR*'s
as well.

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[Steve Hobson]

:>> MVC TARGET(0),SOURCE
:>> EX Rx,*-6

:> Requires a code base register.

Well, ish:

LARL Ry,*+6
MVC TARGET(0),SOURCE
EX Rx,0(,Ry)

or:

BRAS Ry,*+10
MVC TARGET(0),SOURCE
EX Rx,0(,Ry)

BTW, if you include MVI TARGET-1,C' ' somewhere sensible (you only need
to execute it once) then you can do this, which some people think is
elegant:

DC C' '
TARGET DC CLn' '
. . .
MVC TARGET,TARGET-1

[Robin Vowels]

From: "Steve Hobson" <steve_...@uk.ibm.com>
Sent: Wednesday, May 21, 2014 9:38 PM

>For many years I've used this style which I was taught be the legendary
>Pete Roberts:

> MVC TARGET(0),SOURCE
> EX Rx,*-6

I imagine that
EX Rx,*+4
MVC TARGET(0),SOURCE
would be OK too.

>It at least addresses the far-away MVC problem and I imagine helps with
>the ICACHE too.

[Steve Comstock]

On 5/21/2014 8:14 AM, Robin Vowels wrote:
> From: "Steve Hobson" <steve_...@uk.ibm.com>
> Sent: Wednesday, May 21, 2014 9:38 PM
>
>
>> For many years I've used this style which I was taught be the legendary
>> Pete Roberts:
>
>> MVC TARGET(0),SOURCE
>> EX Rx,*-6
>
> I imagine that
> EX Rx,*+4
> MVC TARGET(0),SOURCE
> would be OK too.
>
>> It at least addresses the far-away MVC problem and I imagine helps with
>> the ICACHE too.
>
> ---

Both of these 'solutions' run the MVC instruction
twice. Seems like a waste.

-Steve Comstock

[DASDBILL2]

The *+4 version works equally correctly as the *-6 version.  Both versions will move the first byte twice and all the other bytes once.
I cannot speak for the timing considerations, other than I have used the *+4 version many times in the past in code that would normally execute once per eon.
Bill Fairchild

----- Original Message -----

[Robert Ngan]

For simple moves (i.e. non-padded) longer than 256 bytes and less than 4K,
I've started using MVCOS with R00 set to zero. It's said to be more
expensive than MVC but does anyone know what the "break even" length is
(approximately)?
I'll probable continue using it regardless of the performance penalty since
it's very simple to set up for a variable length move (for lengths longer
than 4K, I'll stick with MVCL).

I'd also be interested in a comparison between EX/MVC and MVCOS if anyone
has that information.

Robert Ngan
CSC Financial Services Group

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
2014/05/20 17:38:06:

[Paul Gilmartin]

On 2014-05-21, at 08:19, Steve Comstock wrote:
>
> Both of these 'solutions' run the MVC instruction
> twice. Seems like a waste.
>

I'd guess, less wasteful than a cache fault.

-- gil

[Tony Harminc]

On 20 May 2014 23:44, Robin Vowels <rob...@dodo.com.au> wrote:
> From: "Tony Harminc" <to...@harminc.com>
> Sent: Friday, May 16, 2014 8:44 AM
>
>> I use MVCL a lot even for very small moves where the length is not
>> known at assembly time. But I know my environment and its performance
>> requirements, and often judge the relative elegance, generality, and
>> programmer-readability of such an instruction to override what small
>> performance gain there might be to multipathing and/or loops.
>
> Sounds like overkill. MVC with EX would be simpler.

For many of my cases it certainly would not. (Unless you mean that
it's simpler for the machine, which I don't care too much about in
this context.)

A current example: I have a field in a data stream containing either a
password or a password phrase, or perhaps neither. I want to copy this
data, which may have any length from 0 to 100 into a new field, and
pad it with zeroes. This is done elegantly by a single MVCL with a
little register setup, much of which can be inherited from previous
MVCLs of related data. It is far more readable than various EXecutes
of MVC, and the source register is left pointing at the next field. It
may have higher overhead than EX/MVC (though it may well not), but
this code isn't in a tight loop doing numerical methods or encryption
or compression, and any excess is completely lost in the larger
transaction processing cost.

Tony H.

[zMan]

I was taught to put the EXecuted instruction elsewhere, AND as the comment,
thus:

EX R1,MVCEX MVC TARGET(*-*),SOURCE

...

MVCEX MVC TARGET(*-*),SOURCE

The "*-*" is an eyecatcher to remind you what's being ORed with the
register. And that this isn't a "real" instruction otherwise (well, yeah,
it'll move ONE byte, but).

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

[zMan]

P.S. That predates concerns about cache lines--maybe slightly not-so-good
nowadays, I guess!

[Rob van der Heij]

So that is to say that the target does come out of the instruction cache
(maybe using the shortcut on ec12).
So it's not just for the reader to see the instruction in line with the
same usings

[Fred van der Windt]

I did a few timing test with MVCOS when it was introduced but it was so shockingly slow that I never touched it again. Many times slower than any construction based on MVCL or an executed MVC.

Might be worth to have another look at it to see if it is faster these days.

Fred!

Sent from my iPhone

-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------

[Robin Vowels]

From: "Steve Hobson" <steve_...@uk.ibm.com>
Sent: Wednesday, May 21, 2014 11:31 PM

>:>> MVC TARGET(0),SOURCE
>:>> EX Rx,*-6

>:> Requires a code base register.

>Well, ish:

> LARL Ry,*+6
> MVC TARGET(0),SOURCE
> EX Rx,0(,Ry)

This (MVC) still requires a base register.

>or:

> BRAS Ry,*+10
> MVC TARGET(0),SOURCE
> EX Rx,0(,Ry)

Ditto.

[McNeill,Cliff]

I am away on vacation. I will be returning Monday June 2, 2014. If this is an emergency please call Susan Kincaid at (713) 745-9311. Or you can page me at (713) 404-9779.

[Robin Vowels]

From: "Binyamin Dissen" <bdi...@dissensoftware.com>
Sent: Wednesday, May 21, 2014 10:03 PM

> On Wed, 21 May 2014 12:38:09 +0100 Steve Hobson <steve_...@uk.ibm.com>
> wrote:
>
> :>> I tend to use MVCL like Tony does. The reason that I tend to not like
> :>doing
> :>> a EX of an MVC is because the MVC needs to be out-of-line. (and is the
> :>MVC
> :>> in the i-cache or the d-cache?) Also, this requires a base register to
> :>> address the area containing the MVC. Which is generally not a problem,
> :>> because I would guess that the MVC would be in the "constants" area of
> :>the
> :>> program. But that moves the MVC far away from the EX instruction. Unless
> :>> you use LOCTR a lot to section up the program. Which can lead to novice
> :>> programmers getting confused. Yes, I know about the "new" EXRL to avoid
> :>the
> :>> need of a base register.
>
> :>For many years I've used this style which I was taught be the legendary
> :>Pete Roberts:
>
> :> MVC TARGET(0),SOURCE
> :> EX Rx,*-6
>
> :>It at least addresses the far-away MVC problem and I imagine helps with
> :>the ICACHE too.
>
> Requires a code base register.

Like many of the original S/360 instructions, that form of MVC will require a base register,
so both the EX and the MVC would be covered by the same base register.

[David Stokes]

Well, two actually, but mostly not a code base, unless one's still writing 1960s non-reentrant code, or source is a constant/literal. We use the old program base register to address the literal and constant pool nowadays, und tend to put the EX target instruction there too, thus killing several birds with one plinth.

(As far as the cache line business is concerned, my view is that it can be significant in certain high performance highly threaded applications, but otherwise largely irrelevant).

-----Ursprüngliche Nachricht-----
Von: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] Im Auftrag von Robin Vowels
Gesendet: Samstag, 24. Mai 2014 13:35

An: ASSEMBL...@LISTSERV.UGA.EDU
Betreff: Re: MVCL

[Carey Schug]

many years ago, in a galaxy far, far away...

I did a benchmark to compare commands for clearing a 255 byte area to zeros.

Going from (IIRC) a 370/168 to a 3033 the order of all methods I checked
exactly reversed, which was, IIRC (might have been 3033 to whatever we had
next)

LM, STM (not a loop, saving then loading 14 registers with zeros, storing
several times)
MVCL
MVC (from zeros)
... (I think there was one or two more which I forget)
overlapping MVC
XC

Yes, the new machine recognized that the XC arguments were the same and
just stored zeros apparently without fetching anything, maybe also
overlapping more with subsequent instructions, since due to a microcode bug
I know XC was greatly overlapped with later instructions..

--
--Carey

[Steve Hobson]

>:>> MVC TARGET(0),SOURCE
>:>> EX Rx,*-6

>:> Requires a code base register.

>>Well, ish:
>
>> LARL Ry,*+6
>> MVC TARGET(0),SOURCE
>> EX Rx,0(,Ry)
>
>This (MVC) still requires a base register.
>
>>or:
>
>> BRAS Ry,*+10
>> MVC TARGET(0),SOURCE
>> EX Rx,0(,Ry)
>
>Ditto.

By "ish" I mean it's a bit moot, depending on what you mean by "requires a
base register". The fragments are usable in code that does not have base
registers for the instructions. Maybe I find that the obvious meaning
because I have been spending a lot of time removing code base registers
from existing code.

If you mean that the registers in the base+displacement SS MVC operands
are called "base" registers then yes, the MVC uses base registers. However
they are not extra registers required over and above what MVCL needs. For
this type of move, MVCL uses a register to contain the address of the
target and a register to contain the address of the source. To argue that
one of the following requires base registers that the other doesn't seems
like pedantry:

MVC 0(0,Ra),0(Rb) Requires base registers Ra and Rb
MVCL Ra,Rb Does not require base registers

Almost all instructions that reference a storage operand need either a
register that contains the address of the operand or that contains the
address of an area that contains the operand (a "base" address).
Ironically, having a base register for the program constants area does not
usually mean you need an extra register; it usually means you need less
registers.

[Rob van der Heij]

It seems to me you're making it harder than it is. Think we referred to
base as the code base for branch instructions and for the target of ex. If
you don't try baseless code you will have the literals often on the same
base as the instructions. And maybe for the target of ex and one of the
operands.
Your wider definition makes almost all have a base. Either your save area
or a control block that you manipulate.
Having seen the impact of cache misses I'm not sure that's trivial. I
recently noted some code here that does a loop over a table with ex to find
the key. Throwing the line out of cache each time because of reference as
code and data might be unwise. But a different algorithm to find the key
might give me even more :-)

[John Gilmore]

I am not sure what purpose is served by obfuscating an ancient piece
of terminology that, for most of its life was neither contentious nor
really ambiguous.

Terms do, of course, acquire new meanings that cannot be ignored, and
in the future I shall call what I have called a base register since
1964 a code-base register (CBR)instead. Fortunately, I find that I
need to talk about CBRs less and less because I now use them very
little.

John Gilmore, Ashland, MA 01721 - USA

[Steve Hobson]

> I am not sure what purpose is served by obfuscating an ancient piece
> of terminology that, for most of its life was neither contentious nor
> really ambiguous.

My apologies. I was not intending to obfuscate but rather to clarify. It
seems I was not successful.

I posted a couple of code fragments in the context of EX+MVC vs MVCL. Two
people pointed out that MVC (and EX for that matter) require a base
register. My "ish" response was not intended to say "you are mistaken", it
was intended to say "that is not really relevant to a discussion of the
relative merits of EX+MVC and MVCL".

Both MVC and MVCL use registers to locate their operands. I am aware that
S-type operands (as in MVC) comprise a base register and a displacement
whereas R-type operands that contain an address (as in MVCL) are not
actually called "base registers".

But in both cases the instructions specify (as they logically must)
registers that address the data. Whether or not they are "base" registers
doesn't make a difference to the relative parsimony of the code w/r/t
registers used.

[Binyamin Dissen]

When "it requires a base register" is stated, it obviously means a CODE base
register. One wonders how that can be confused.

On Mon, 26 May 2014 00:42:11 +0100 Steve Hobson <steve_...@uk.ibm.com>
wrote:

:>> I am not sure what purpose is served by obfuscating an ancient piece

:>> of terminology that, for most of its life was neither contentious nor
:>> really ambiguous.
:>
:>My apologies. I was not intending to obfuscate but rather to clarify. It
:>seems I was not successful.
:>
:>I posted a couple of code fragments in the context of EX+MVC vs MVCL. Two
:>people pointed out that MVC (and EX for that matter) require a base
:>register. My "ish" response was not intended to say "you are mistaken", it
:>was intended to say "that is not really relevant to a discussion of the
:>relative merits of EX+MVC and MVCL".
:>
:>Both MVC and MVCL use registers to locate their operands. I am aware that
:>S-type operands (as in MVC) comprise a base register and a displacement
:>whereas R-type operands that contain an address (as in MVCL) are not
:>actually called "base registers".
:>
:>But in both cases the instructions specify (as they logically must)
:>registers that address the data. Whether or not they are "base" registers
:>doesn't make a difference to the relative parsimony of the code w/r/t
:>registers used.

[David Stokes]

Binyamin Dissen wrote:
>>When "it requires a base register" is stated, it obviously means a CODE base
>>register. One wonders how that can be confused.

Why? (It's use of terminology, not confusion). Storage addresses in z/Architecture are Base/Displacement, or direct register addresses. A base register doesn't necessarily refer to storage containing instructions. There is no technical difference between a "code base" and any other base register, so to claim there is seems to me to be confusing the issue. To address a field in a DSECT (usually) "requires a base register". ("Now I need another register to base this new DSECT"?) We have one or two bits of code that are set up in dynamic storage and addressed via the DSECT base register. Is that also then a code base? Also an MVC may or may not need a "code base register", if it is a code base when addressing constants. Is the base needed by EX a cbr, because its target is an instruction? Or is that just a, hmm, non-cbr (non?)br? Fragen über Fragen. Of course, MVCL does not use a base, of whatever sort.

[John Gilmore]

It is now clear that we are dealing here with neither confusion nor
disagreement alone but with an unholy admixture of both.

It cannot be remedied by fiat. David Stokes writes of addressing a
field in a DSECT using a base register, 'basing' a DSECT. I do not.
I talk and write about 'mapping' storage using a DSECT as a template.
In any case a register is [usually] required, and David is free to
call it a base register if he wishes.

Steve Hobson's second-time-around distinction:

<begin extract>

Both MVC and MVCL use registers to locate their operands. I am aware
that S-type operands (as in MVC) comprise a base register and a
displacement whereas R-type operands that contain an address (as in
MVCL) are not actually called "base registers".

</end extract>

is the one I was trying to preserve. [I should have written "whereas
the registers that contain R-type operands" instead, but I am a
notorious use-and-mention pedant.]


--

[Robin Vowels]

From: "David Stokes" <Sto...@interchip.de>
Sent: Monday, May 26, 2014 5:47 PM

Um, how do you get addresses into the relevant registers required by MVCL?

[Paul Gilmartin]

On 2014-05-26, at 07:59, Robin Vowels wrote:
>
> Um, how do you get addresses into the relevant registers required by MVCL?
>

ADCONs?

-- gil

[John McKown]

LOAD, LOAD ADDRESS, LOAD ADDRESS RELATIVE LONG come to mind off hand.

[John Gilmore]

I suspect that Robin's question was rhetorical/tongue-in-cheek, not a
request for information. He is a very old hand at this game.

[David Stokes]

Well, there's no doubt a more witty response to this unpleasant bit of JG calumny, but I'm getting too old to bother that much, and anyway, why waste it? Just read POP where it states under Operand-Address Generation "The base address (B) is a 64-bit number contained in a general register specified by the program in a four bit field, called the B field, in the instruction...The displacement (D) is a 12-bit or 20-bit number contained in a field, called the D field, in the instruction". Also in HLASM describing DSECTs it states "Provide [a] USING statement that specifies...a general register that the assembler can use as a base register for the dummy section..."

So that's a base register (or two) in an instruction such as MVC, whether JG agrees or not. Which is also the common usage I've encountered programming (z/)OS assembler since around 1966, and still do. And which is what Steve Hobson apparently said as well, funnily enough. That a DSECT maps storage no one will dispute, but no one outside of forums like this actually says "I've mapped the storage with this DSECT" since we all know what a DSECT does.



-----Ursprüngliche Nachricht-----
Von: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] Im Auftrag von John Gilmore
Gesendet: Montag, 26. Mai 2014 14:16

An: ASSEMBL...@LISTSERV.UGA.EDU
Betreff: Re: MVCL

[David Stokes]

The same way you do it with base registers for MVC or anything else you address with registers? Does the question have some point?

-----Ursprüngliche Nachricht-----
Von: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] Im Auftrag von Robin Vowels
Gesendet: Montag, 26. Mai 2014 15:59

An: ASSEMBL...@LISTSERV.UGA.EDU
Betreff: Re: MVCL

[John Gilmore]

David Stokes saw calumny---a lie spoken or written to damage someone
else's reputation---where none was intended. I suspect that he did
not know quite what this word means. Now he does.

[John Gilmore]

--

[Robin Vowels]

From: "Binyamin Dissen" <bdi...@dissensoftware.com>
Sent: Monday, May 26, 2014 3:51 PM

> When "it requires a base register" is stated, it obviously means a CODE base
> register.

No it doesn't. A base register is a base register.

[Scott Ford]

No such animal as a code base register unless this is some slang …There are BASE and BASELESS HLASM code.




Regards,

Scott

[David Stokes]

Well thank you, Mr G. But better not to be drawn in further.

-----Ursprüngliche Nachricht-----
Von: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] Im Auftrag von John Gilmore
Gesendet: Montag, 26. Mai 2014 21:50

An: ASSEMBL...@LISTSERV.UGA.EDU
Betreff: Re: MVCL

[Ed Jaffe]

On 5/26/2014 6:57 PM, Scott Ford wrote:
> No such animal as a code base register unless this is some slang …There are BASE and BASELESS HLASM code.

In this context, "baseless" must be some sort of slang.

There are based branches and there are relative branches. Use of
relative branches in a program can eliminate the need for base register
coverage of all or most of the code. But, unless your program is only a
few lines long, it's impossible to eliminate entirely the need for base
register(s) covering at least constants and literals. This distinction
is what gives rise to the notion of a "code base register" which I think
is a very appropriate and descriptive term.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

[Peter Relson]

I think of

- Code (base) register: generally old style, when relative addressing is
not available
- Static Area (base) register: address of your static data (such as
literals)
Some modules actually have no such data but most do.
z/OS macros may assume that you have addressability to such an area,
or (fewer, at least when IEABRC(X) is used) they
may assume that you have code register addressability.
- Dynamic Area (base) register: address of the area that you obtained on
module
entry for working storage

These show up as, but are not really the same term, as the "base register"
of architected instructions.

Peter Relson
z/OS Core Technology Design

[Duffy Nightingale]

I've always done the ex of mvc thusly:

EX R1,TEXT8000 MOVE IN ASCII NUMBERS

Down where it will not be executed

TEXT8000 DS 0H
MVC 0(*-*,R6),B24AN FROM WORK TO OUTPUT ASCII

Duffy

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Steve Comstock
Sent: Wednesday, May 21, 2014 7:19 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: MVCL

On 5/21/2014 8:14 AM, Robin Vowels wrote:
> From: "Steve Hobson" <steve_...@uk.ibm.com>
> Sent: Wednesday, May 21, 2014 9:38 PM

>
>
>> For many years I've used this style which I was taught be the
>> legendary Pete Roberts:
>
>> MVC TARGET(0),SOURCE
>> EX Rx,*-6
>

> I imagine that
> EX Rx,*+4
> MVC TARGET(0),SOURCE
> would be OK too.

>
>> It at least addresses the far-away MVC problem and I imagine helps
>> with the ICACHE too.
>

> ---

Both of these 'solutions' run the MVC instruction twice. Seems like a waste.

-Steve Comstock

[Bowers, Greg]

I am out of the office and will be returning Monday Jun 23. If you need immediate assistance please contact Robert H Lewis. Otherwise, I will reply to messages when I return.

Thank you,
Greg Bowers

[Robin Vowels]

From: "Duffy Nightingale" <du...@soundsoftware.us>
Sent: Monday, June 16, 2014 5:27 AM

> I've always done the ex of mvc thusly:
>
> EX R1,TEXT8000 MOVE IN ASCII NUMBERS
>
> Down where it will not be executed
>
> TEXT8000 DS 0H
> MVC 0(*-*,R6),B24AN FROM WORK TO OUTPUT ASCII

Some folks prefer to have the MVC close by.
The full sequence would be:
LTR R1,R1
BZ SKIP
BCTR R1,0
EX R1, TEXT8000
SKIP ...

> Duffy
>
> -----Original Message-----
> From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Steve
> Comstock
> Sent: Wednesday, May 21, 2014 7:19 AM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: MVCL
>
> On 5/21/2014 8:14 AM, Robin Vowels wrote:
>> From: "Steve Hobson" <steve_...@uk.ibm.com>
>> Sent: Wednesday, May 21, 2014 9:38 PM
>>
>>
>>> For many years I've used this style which I was taught be the
>>> legendary Pete Roberts:
>>
>>> MVC TARGET(0),SOURCE
>>> EX Rx,*-6
>>
>> I imagine that
>> EX Rx,*+4
>> MVC TARGET(0),SOURCE
>> would be OK too.
>>
>>> It at least addresses the far-away MVC problem and I imagine helps
>>> with the ICACHE too.
>>
>> ---
>
> Both of these 'solutions' run the MVC instruction twice. Seems like a waste.
>
> -Steve Comstock

[Wojtczak Arkadiusz]

Dzień dobry,
do 15 czerwca przebywam poza biurem. Poczta nie jest przekierowywana.
W sprawach pilnych proszę o kontakt z Krzysztofem Szubą lub Jakubem Teską.
Pozdrawiam,
Arkadiusz Wojtczak

[Tom Marchant]

On Mon, 16 Jun 2014 11:34:50 +1000, Robin Vowels wrote:

>From: "Duffy Nightingale" <du...@soundsoftware.us>
>Sent: Monday, June 16, 2014 5:27 AM
>
>
>> I've always done the ex of mvc thusly:
>>
>> EX R1,TEXT8000 MOVE IN ASCII NUMBERS
>>
>> Down where it will not be executed
>>
>> TEXT8000 DS 0H
>> MVC 0(*-*,R6),B24AN FROM WORK TO OUTPUT ASCII
>
>Some folks prefer to have the MVC close by.
>The full sequence would be:
> LTR R1,R1
> BZ SKIP
> BCTR R1,0
> EX R1, TEXT8000

You didn't show the MVC, but when you said you prefer it to be
"close by", perhaps you meant that you would put it immediately
before or after the EX. Some like to keep it close without an
additional execution by coding:

EX R1,TEXT8000 MOVE IN ASCII NUMBERS

DATA LOCTR

TEXT8000 DS 0H
MVC 0(*-*,R6),B24AN FROM WORK TO OUTPUT ASCII

CODE LOCTR

--
Tom Marchant

[Zeitounlian, Armenio]

I will be on vacation between Jun 16 and Jul 15 (both days included). If you need to open an issue with me, please open it via (11)55036100 or via support.ca.com, and someone will contact you.

[Paul Gilmartin]

On 2014-06-16, at 10:30, Tom Marchant wrote:
>
> You didn't show the MVC, but when you said you prefer it to be
> "close by", perhaps you meant that you would put it immediately
> before or after the EX. Some like to keep it close without an
> additional execution by coding:
>
> EX R1,TEXT8000 MOVE IN ASCII NUMBERS
> DATA LOCTR
> TEXT8000 DS 0H
> MVC 0(*-*,R6),B24AN FROM WORK TO OUTPUT ASCII
> CODE LOCTR
>

o Source code is easiest to read.

o Fewest USING-DROP pitfalls.

o Dumps may be harder to read and correlate with SYSPRINT.
(Is there a utility to assist this; perhaps an IPCS function?)

o LoR for cache management not guaranteed.

-- gil

[Robin Vowels]

----- Original Message -----
From: "Tom Marchant" <m42tom-...@YAHOO.COM>
To: <ASSEMBL...@LISTSERV.UGA.EDU>
Sent: Tuesday, June 17, 2014 2:30 AM
Subject: Re: MVCL


> On Mon, 16 Jun 2014 11:34:50 +1000, Robin Vowels wrote:
>
>>From: "Duffy Nightingale" <du...@soundsoftware.us>
>>Sent: Monday, June 16, 2014 5:27 AM
>>
>>
>>> I've always done the ex of mvc thusly:
>>>
>>> EX R1,TEXT8000 MOVE IN ASCII NUMBERS
>>>
>>> Down where it will not be executed
>>>
>>> TEXT8000 DS 0H
>>> MVC 0(*-*,R6),B24AN FROM WORK TO OUTPUT ASCII
>>
>>Some folks prefer to have the MVC close by.
>>The full sequence would be:
>> LTR R1,R1
>> BZ SKIP
>> BCTR R1,0
>> EX R1, TEXT8000
>
> You didn't show the MVC,

Obviously, it's the same as Duffy's, at location TEXT8000

> but when you said you prefer it to be "close by",

No I didn't. I said, by way of explation to Duffy, that some folks prefer it close by. I don't.

> perhaps you meant that you would put it immediately
> before or after the EX.

Obviously not (and certainly not before, because it isn't shown).

> Some like to keep it close without an
> additional execution by coding:
>
> EX R1,TEXT8000 MOVE IN ASCII NUMBERS
> DATA LOCTR
> TEXT8000 DS 0H
> MVC 0(*-*,R6),B24AN FROM WORK TO OUTPUT ASCII
> CODE LOCTR

[Ken Brick]

Could someone please unsubscribe this email from the list as Ken passed away
several months ago and I am trying to sort out his emails.
Regards,
Rachael

----- Original Message -----
From: <ess...@juno.com>
To: <ASSEMBL...@LISTSERV.UGA.EDU>
Sent: Sunday, April 20, 2014 4:35 AM
Subject: ASMA034E


> hello
>
> I know this topic has been discussed before..
> Im on a Z/OS 1.7 system with HLASM R5.0
> ...
> Im trying to maintain the concept of "Baseless Code" in some programs, I
> keep running into some macros on Z/os 1.7 that use BAL R15,*+20
> .
> .
> And as such i receive message
> ** ASMA034E Operand *+20 beyond active USING range by 185 bytes
> ** ASMA435I Record 124 in SYS1.MACLIB(IHBINNRB) on volume: S7RES1
> .
> .
> I could move the routine to another location in this module, and that
> would avoid the ASMA034E. Is there a recommended technique to use where I
> could convert the BAL instruction in the macro to another branch
> instruction ?
> .
> .
> Paul D'Angelo

[Stan Saraczewski]

Rachael - I'm sorry...

[David de Jongh]

Rachel,
My condolences for your loss.

To unsubscribe, send a message with no subject , and the following text in
the message body to LIST...@uga.cc.uga.edu:

SIGNOFF ASSEMBLER-LIST

You can also sign off from all lists with :

SIGNOFF *

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Ken Brick
Sent: Monday, June 30, 2014 1:33 AM
To: ASSEMBL...@LISTSERV.UGA.EDU