Base registers

[Scott Ford]

Guys/Gals:
 
I am the process of modifying our IRREVX01 and have a fundamental question...Currently when the exit is called the prolog looks like this:
 
LOGEVX01 CSECT ,
LOGEVX01 AMODE 31
LOGEVX01 RMODE ANY
         YREGS
         SAVE  (14,12)
         LR    R12,R15             program addressability
         USING LOGEVX01,R12        set base register
         LR    R10,R1              save parameter address
         USING EVXPL,R10           base parameter map
         L     R3,EVXFLAGS         exit flag address
         TM    0(R3),EVXPOST       post-exit ?
         BNO   GOBACK              if not, get out
 
Which works fine . I have added new code and exceeded the initial register cover range of 4k ..I tried to add an addition base
register like this:
 
LOGEVX01 CSECT ,
LOGEVX01 AMODE 31
LOGEVX01 RMODE ANY
         YREGS
         SAVE  (14,12)
         LR    R12,R15             program addressability
         LA    R12,2048(R11)
         LA    R12,2048(R12)
         USING LOGEVX01,R11,R12       set base register
         LR    R10,R1              save parameter address
         USING EVXPL,R10           base parameter map
         L     R3,EVXFLAGS         exit flag address
         TM    0(R3),EVXPOST       post-exit ?
         BNO   GOBACK              if not, get out
 
Assembled and liked the exit, T PROG=xx  , where xx is the parmlib member to delete the exit
Reloaded the exit via T PROG=yy to activate the exit .
 
Ran a test through the exit ( a RACF command ) and a S0C1-1
Without the addition of the new lines for the second base register. The exit works fine..
 
Either I blew it on the second base or IRREVX01 has a size restriction ...
 
Can someone point me the right way ?
 
 
Thanks in advance..

Regards 
Scott J Ford
Software Engineer
http://www.identityforge.com

[Mark Vitale]

On 6/1/12 10:25 AM, "Scott Ford" <scott_...@yahoo.com> wrote:

> LR R12,R15 program addressability
> LA R12,2048(R11)
> LA R12,2048(R12)
> USING LOGEVX01,R11,R12 set base register

another possibility, lets you keep the base regs in "order" R11,R12:

LR R11,R15 program addressability

[Chuck Arney]

Scott, your reply-to on your list posts is set to your email address instead
of the list.

As I said privately (not on purpose), change the LR R12,R15 to LR R11,R12 or
change your other instructions to load R11 and use R12,R11.

Chuck Arney
Arney Computer Systems

[Kirk Talman]

Why not just change the code to baseless? I have done that with various
things I touched over the last decade to good effect. Now that I am back
in a group that does assembler, I look forward to doing more.

Start with subroutines using LOCTR

* at top of code after CSECT
BASED LOCTR ,
.
.
.
JAS R14,SUB1
.
.
BASELESS LOCTR ,
* begin subroutine
SUB1 DS 0H
.
.
.
BR R14
* end of subroutine
BASED LOCTR ,
.
.
.

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
06/01/2012 10:44:15 AM:

> From: Chuck Arney <ch...@arneycomputer.com>
>
> Scott, your reply-to on your list posts is set to your email address
instead
> of the list.
>
> As I said privately (not on purpose), change the LR R12,R15 to LR
R11,R12 or
> change your other instructions to load R11 and use R12,R11.
>
> Chuck Arney
> Arney Computer Systems
>
> -----Original Message-----
> From: IBM Mainframe Assembler List [
mailto:ASSEMBL...@LISTSERV.UGA.EDU]
>

-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you

[Binyamin Dissen]

Best approach is to use IEABRC and use baseless coding. Move all your data to
the end and use LARL to set a base register.

In your case you are telling the assembler that R11 is a base but you never
set it.

On Fri, 1 Jun 2012 07:25:45 -0700 Scott Ford <scott_...@yahoo.com> wrote:

:>Guys/Gals:

--
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.

[Scott Ford]

Thanks guys, I am looking at Ed's Share presentation. ty a bunch.wow I missed a lot. Like Kirk my assembler brain and eyes are coming back. We work in Java,Cobol,C and Assembler...So i have go back and forth ...
 
Thanks again

Scott J Ford
Software Engineer
http://www.identityforge.com
 

________________________________
From: Binyamin Dissen <bdi...@dissensoftware.com>
To: ASSEMBL...@LISTSERV.UGA.EDU
Sent: Friday, June 1, 2012 11:11 AM
Subject: Re: Base registers

[Robert A. Rosenberg]

At 07:25 -0700 on 06/01/2012, Scott Ford wrote about Base registers:

>Guys/Gals: I am the process of modifying our IRREVX01 and have a
>fundamental question...Currently when the exit is called the prolog
>looks like this: LOGEVX01 CSECT , LOGEVX01 AMODE 31 LOGEVX01 RMODE
>ANY YREGS SAVE (14,12) LR R12,R15
>program addressability USING LOGEVX01,R12 set base
>register LR R10,R1 save parameter address
>USING EVXPL,R10 base parameter map L
>R3,EVXFLAGS exit flag address TM 0(R3),EVXPOST
>post-exit ? BNO GOBACK if not, get out
>Which works fine . I have added new code and exceeded the initial
>register cover range of 4k ..I tried to add an addition base
>register like this: LOGEVX01 CSECT , LOGEVX01 AMODE 31 LOGEVX01
>RMODE ANY YREGS SAVE (14,12) LR
>R12,R15 program addressability LA
>R12,2048(R11) LA R12,2048(R12)

This should be:
LA R11,2048(R12)
LA R11,2048(R11)

You were destroying R12 by loading it with whatever was in R11+4096

[Steve Mondy]

I am currently out of the office. For assistance please contact:
Pat Bowman at pat.b...@opensolutions.com, 713.965.1458
Ray Waters at ray.w...@opensolutions.com, 713.965.8451.


________________________________

NOTICE:
This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You.

[Bob Rutledge]

Robert A. Rosenberg wrote:
> At 07:25 -0700 on 06/01/2012, Scott Ford wrote about Base registers:
>
>> Guys/Gals: I am the process of modifying our IRREVX01 and have a
>> fundamental question...Currently when the exit is called the prolog
>> looks like this: LOGEVX01 CSECT , LOGEVX01 AMODE 31 LOGEVX01 RMODE
>> ANY YREGS SAVE (14,12) LR R12,R15
>> program addressability USING LOGEVX01,R12 set base
>> register LR R10,R1 save parameter address
>> USING EVXPL,R10 base parameter map L
>> R3,EVXFLAGS exit flag address TM 0(R3),EVXPOST
>> post-exit ? BNO GOBACK if not, get out
>> Which works fine . I have added new code and exceeded the initial
>> register cover range of 4k ..I tried to add an addition base
>> register like this: LOGEVX01 CSECT , LOGEVX01 AMODE 31 LOGEVX01
>> RMODE ANY YREGS SAVE (14,12) LR
>> R12,R15 program addressability LA
>> R12,2048(R11) LA R12,2048(R12)
>
> This should be:
> LA R11,2048(R12)
> LA R11,2048(R11)

This will work only if you adjust the USING to match it.

> You were destroying R12 by loading it with whatever was in R11+4096
>
>> USING LOGEVX01,R11,R12 set base register LR
>> R10,R1 save parameter address USING EVXPL,R10
>> base parameter map L R3,EVXFLAGS exit flag
>> address TM 0(R3),EVXPOST post-exit ? BNO
>> GOBACK if not, get out Assembled and liked the exit,
>> T PROG=xx , where xx is the parmlib member to delete the exit
>> Reloaded the exit via T PROG=yy to activate the exit . Ran a test
>> through the exit ( a RACF command ) and a S0C1-1 Without the
>> addition of the new lines for the second base register. The exit
>> works fine.. Either I blew it on the second base or IRREVX01 has a
>> size restriction ... Can someone point me the right way ?
>> Thanks in advance.. Regards Scott J Ford Software Engineer
>> http://www.identityforge.com
>

Bob

[Robert A. Rosenberg]

At 18:44 -0400 on 06/01/2012, Bob Rutledge wrote about Re: Base registers:

> >
>> This should be:
>> LA R11,2048(R12)
>> LA R11,2048(R11)
>
>This will work only if you adjust the USING to match it.
>
>
>> You were destroying R12 by loading it with whatever was in R11+4096
>>
> >> USING LOGEVX01,R11,R12 set base register

OOPS you're right. His LAs were correct BUT the LR R12,R15 after the
SAVE should have been a LR R11,R15. Otherwise my reply was correct if
the USING was updated as you point out.

[robin]

From: Robert A. Rosenberg
Sent: Saturday, 2 June 2012 7:04 AM

> LA R11,2048(R12)
> LA R11,2048(R11)

LA 11,4095(0,12)

requires only one instruction (adjust USING accordingly).

[Bodoh John Robert]

Why not:

ALFI R11,4096

John

[Chuck Arney]

I don't think you really want your base register pointing to an odd address.
You need to add 1 more to make it right and that requires another
instruction.

Chuck Arney
Arney Computer Systems

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of robin
Sent: Saturday, June 02, 2012 8:12 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Base registers

[David Bond]

Only one instruction is required:
LAY R11,4096(,R12)

But really, for over 15 years base registers are only required for data
areas. Just use LA, LAY or LARL to address the first data item and base the
USING from there. Also switch from branches (Bc, BAS, BCT...) to jumps (Jc,
JAS, JCT...).

On Sat, 2 Jun 2012 15:53:59 -0500, Chuck Arney wrote:
>I don't think you really want your base register pointing to an odd address.
>You need to add 1 more to make it right and that requires another
>instruction.
>
>Chuck Arney
>Arney Computer Systems
>
>-----Original Message-----
>From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
>On Behalf Of robin
>Sent: Saturday, June 02, 2012 8:12 AM
>

[Trivers Software]

I agree with Chuck, in fact this is on our interview test!
anyone who sets up the 2nd -> nn base registers with 4095, has obviously
never had to prepare maint. via a zap!
So they would never be hired!

[John Gilmore]

David Bond writes:

<begin extract>

But really, for over 15 years base registers are only required for
data areas. Just use LA, LAY or LARL to address the first data item
and base the USING from there. Also switch from branches (Bc, BAS,
BCT...) to jumps (Jc, JAS, JCT...).

</end extract>

Indeed! There is a case--a strong one--for using traditional methods
in patching old code; but there is none to be made for doing so in
writing even a new single RSECT.

The two-base-register case for something just a bit over 4096 bytes in
length is a particularly egregious, hidebound use of obsolete
technology. Let's stop it.

John Gilmore, Ashland, MA 01721 - USA

[Chuck Arney]

Certainly I'm not suggesting this is the best approach to handle new code
updates. I'm only pointing out that the previous advice on how to correct
the described problem is incorrect. I'm sure we could all come up with many
other ways to load base registers or even eliminate them.

Chuck Arney
Arney Computer Systems

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

On Behalf Of David Bond
Sent: Saturday, June 02, 2012 5:13 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Base registers

[Tony Thigpen]

> but there is none to be made for doing so in
> writing even a new single RSECT.

How about this reason.

We have several customers running our software that are on pre-MP3000
machines that don't even support relative instructions. They still pay
us for support and that includes software upgrades.

Other vendors may not care about existing customers, but we do.

Almost all of these customers also can't upgrade their VSE. They fell
into the ESL trap with IBM many years ago and now can't get their budget
dollars back to get current because of the IBM monthly charges. As
faithful customers for many years, we do not want to kick them while
they are down just so we can do 'fancier' code.

Tony Thigpen

[Robert A. Rosenberg]

At 15:49 -0700 on 06/02/2012, Trivers Software wrote about Re: Base registers:

>I agree with Chuck, in fact this is on our interview test!
>anyone who sets up the 2nd -> nn base registers with 4095, has obviously
>never had to prepare maint. via a zap!
>So they would never be hired!

Once I have a 3rd base register, I use this sequence (in lieu of the
two instruction per register LA RX,2048... version) to load. If my
BASE is R12, and I want to add R9-R11 as extra bases:

LA R9,4095 Prime R9 with 4096
LA R11,1(R9,R12) R11=R12+4096
LA R10,1(R9,R11) R10=R11+4096
LA R9,1(R9,R10) R9=R10+4096

[Gerhard Postpischil]

On 6/2/2012 6:57 PM, John Gilmore wrote:
> The two-base-register case for something just a bit over 4096 bytes in
> length is a particularly egregious, hidebound use of obsolete
> technology. Let's stop it.

As they say, all generalities are false. Some of us write dual
mode code, to be used both on modern systems and on traditional
ones. The Hercules groups for DOS, MVT, and MVS have hundreds of
users, and legacy systems and software are alive and well.
Running old programs as a hobby is considerably less expensive
than many others, and may even help delay the onset of Alzheimer's.

Gerhard Postpischil
Bradford, VT

[Binyamin Dissen]

On Sun, 3 Jun 2012 02:52:11 -0400 Gerhard Postpischil <ger...@valley.net>
wrote:

The eternal separation between practical business programming and
pie-in-the-sky elitism.

[John Gilmore]

Tony Thigpen wrote:

<begin extract>

We have several customers running our software that are on pre-MP3000
machines that don't even support relative instructions. They still pay
us for support and that includes software upgrades.

Other vendors may not care about existing customers, but we do.

</end extract>

Gerhard Postpischil wrote:

<begin extract>

As they say, all generalities are false. Some of us write dual mode
code, to be used both on modern systems and on traditional ones. The
Hercules groups for DOS, MVT, and MVS have hundreds of users, and
legacy systems and software are alive and well.
Running old programs as a hobby is considerably less expensive than
many others, and may even help delay the onset of Alzheimer's.

</end extrract>

Binyamin Dissen wrote:

<begin extract>

The eternal separation between practical business programming and
pie-in-the-sky elitism.

</end extract>

Let me deal with them in reverse order.

Binyamin's argument is ad hominem, name-calling; and that is enough to
say about it. For the record, I will, however, note that, while I
like 'pie in the sky', resonant as it is of Joe Hill and the IWW, it
combines badly with '�litist'.

Gerhard's point is not so easily dismissed; but 1) it is
self-defeating for the technology if pushed very far: it freezes
software in a posture that is now more than fifteen years behind the
state of the art; and 2) the market for even moderately-priced
software among MVT-using hobbyists is very small. Still, seriously
pursued dual-path software is is certainly viable.

Tony's argument surprised me a little in two ways. I was surprised by
the apparent size of the market he describes and by his vehemence,
both of which may reflect special characteristics of VSE users, about
whom I know too little. In his circumstances dual paths would also
seem to be appropriate.

As a now certified �litist, I am nevertheless unrepentent. Urgings
about compatibility requirements and the like usually hide Luddite
impulses, reluctance to accommodate the (not very) new, which account
for a good many of the troubles that the mainframe community is
experiencing.

[Scott Ford]

Robert,

Thank you I appreciate the help been writing assembler a long time but not consistently every day. I have had to wear many function hats, sysprog vm,VSE,CICS,vtam ,tcpip, network engineer, etc. So I got rusty in assembler, I think everyone on here are very helpful..and it is appreciated.

Scott ford
www.identityforge.com

[Scott Ford]

John,

In am far from a Luddite , but I think you have to have need, i.e. project or task to want to change code. My need is a rather large exit we use for RACF. I inherited the exit , so I am trying to
Incorporate modern methods and functionality in our code. When your making money off your code , like we do as a vendor , you look at things differently and IMHO you have a responsibility to your customers, yes we are very customer sensitive.

Scott ford
www.identityforge.com

> combines badly with 'élitist'.

>
> Gerhard's point is not so easily dismissed; but 1) it is
> self-defeating for the technology if pushed very far: it freezes
> software in a posture that is now more than fifteen years behind the
> state of the art; and 2) the market for even moderately-priced
> software among MVT-using hobbyists is very small. Still, seriously
> pursued dual-path software is is certainly viable.
>
> Tony's argument surprised me a little in two ways. I was surprised by
> the apparent size of the market he describes and by his vehemence,
> both of which may reflect special characteristics of VSE users, about
> whom I know too little. In his circumstances dual paths would also
> seem to be appropriate.
>

> As a now certified élitist, I am nevertheless unrepentent. Urgings

[Binyamin Dissen]

On Sun, 3 Jun 2012 12:38:07 -0400 Scott Ford <scott_...@yahoo.com> wrote:

:>John,

:>
:>In am far from a Luddite , but I think you have to have need, i.e. project or task to want to change code. My need is a rather large exit we use for RACF. I inherited the exit , so I am trying to
:>Incorporate modern methods and functionality in our code. When your making money off your code , like we do as a vendor , you look at things differently and IMHO you have a responsibility to your customers, yes we are very customer sensitive.

Very well put. You cannot force customers to upgrade, and you must enhance if
you want the maintenance revenue stream.

Academics are free to postulate otherwise.

:>> combines badly with '�litist'.

:>>
:>> Gerhard's point is not so easily dismissed; but 1) it is
:>> self-defeating for the technology if pushed very far: it freezes
:>> software in a posture that is now more than fifteen years behind the
:>> state of the art; and 2) the market for even moderately-priced
:>> software among MVT-using hobbyists is very small. Still, seriously
:>> pursued dual-path software is is certainly viable.
:>>
:>> Tony's argument surprised me a little in two ways. I was surprised by
:>> the apparent size of the market he describes and by his vehemence,
:>> both of which may reflect special characteristics of VSE users, about
:>> whom I know too little. In his circumstances dual paths would also
:>> seem to be appropriate.
:>>

:>> As a now certified �litist, I am nevertheless unrepentent. Urgings

:>> about compatibility requirements and the like usually hide Luddite
:>> impulses, reluctance to accommodate the (not very) new, which account
:>> for a good many of the troubles that the mainframe community is
:>> experiencing.
:>>
:>> John Gilmore, Ashland, MA 01721 - USA

[John Gilmore]

In my original post I noted that old code should be maintained using
the technology in which it was written, typically using base registers
for code addressability.

Moreover, it is clear enough that ISVs must be customer-sensitive if
they are to survive.

These things said, there is still far too much HLASM code being
written using methods that have been, at best, obsolescent for many,
many years.

With this post I have said enough, maybe too much, about this topic.

[Robert A. Rosenberg]

At 12:21 -0400 on 06/03/2012, Scott Ford wrote about Re: Base registers:

>Robert,
>
>Thank you I appreciate the help been writing assembler a long time
>but not consistently every day. I have had to wear many function
>hats, sysprog vm,VSE,CICS,vtam ,tcpip, network engineer, etc. So I
>got rusty in assembler, I think everyone on here are very
>helpful..and it is appreciated.
>
>Scott ford
>www.identityforge.com

Some times you just run into a cute (or non-standard) trick with
assembler. My favorite is the use of the TR command to do a patterned
move (when the source and target are both under 256 bytes in length).
You fill in the target area with offsets into the source and then TR
the target using the source as the TR Table. This was a trick to flip
the order of the bytes in a field (so it reads right to left) before
MVCI was added to the instruction set. The major effort is in
generating the offset mask in the first place. For the invert the
order case you just assume the mask as:

MASK DC 256AL1(MASK+255-*) 255,254,253,...,2,1,0

[Scott Ford]

Robert,

I seem remember something similar..I worked a vm/VSE shop for awhile, the good ole card days, we would want a jcl card deck listing, originally written in COBOL it did a perform 1 by 1 varying, I changed it to something similar to what you mentioned, worked as well as as fast..that was a macro CICS shop too, man, a lot of storage violations...boy

Scott ford
www.identityforge.com

[robin]

From: Chuck Arney
Sent: Sunday, 3 June 2012 6:53 AM

>I don't think you really want your base register pointing to an odd address.
>You need to add 1 more to make it right and that requires another
>instruction.

There's no need to be scared of an odd value.
It is, after all, the assembler that calculates displacements.
If it bothers you, make it 4092. Still no extra instruction needed.

[Rob van der Heij]

On Mon, Jun 4, 2012 at 2:45 AM, robin <rob...@dodo.com.au> wrote:

> There's no need to be scared of an odd value.
> It is, after all, the assembler that calculates displacements.
> If it bothers you, make it 4092. Still no extra instruction needed.

Since most of the time you just new a few more bytes anyway ;-)

[Gerhard Postpischil]

On 6/3/2012 8:52 AM, John Gilmore wrote:
> Gerhard's point is not so easily dismissed; but 1) it is
> self-defeating for the technology if pushed very far: it freezes
> software in a posture that is now more than fifteen years behind the
> state of the art; and 2) the market for even moderately-priced
> software among MVT-using hobbyists is very small. Still, seriously
> pursued dual-path software is is certainly viable.

Supporting obsolete systems is a labor of love; I see no reason
to impute financial objectives to their support. For example,
Dave Cole has offered the MVS version of XDC for free, except no
copy of this version of it has been found.

> As a now certified �litist, I am nevertheless unrepentent. Urgings
> about compatibility requirements and the like usually hide Luddite
> impulses, reluctance to accommodate the (not very) new, which account
> for a good many of the troubles that the mainframe community is
> experiencing.

If I were responsible for a Fortune 500 company, I would be
leery of making changes solely to avoid consideration as a
Luddite. And for a mission critical business application, I
certainly would prefer a machine optimized compiler over
assembler (programmers should provide global optimization).

My approach is pragmatic - use the appropriate tools best suited
for the task at hand. If that means consciously deciding on old
code reuse rather than new development, that may prove faster
and cheaper in the long run. But I agree that old code should
not be used simply because a programmer is not up to speed on
new features.

Gerhard Postpischil
Bradford, VT

[Martin Truebner]

>> Odd (or nonconsecutive) Base registers

Please-

If there is ever a need to calculate a ZAP to this code with crossing
the boundary between two registers- it will cause major headaches-

The PLS compiler does it- but this is not an argument to do it.

--
Martin

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

[Martin Trübner]

>> ... said enough, maybe too much, about this topic

Since the thread is still not dead- here is my point:

Use of relative & immediate feature is the way to go. The time it takes
to convert a module from Bxx type to Jxxx is neglectable in comparison
to finding an unused register (or restructuring to get one).

The major roadblock is codealterations (switches in code) = not
reentrant. Which I assume is not the case for a IRREVX01 exit
(shudder: and sold as a part of a product).

And to those refusing to use "new" techniques. How old has a feature to
be to be usable for code? This is more than 17 years old (*).

I have yet to find that VSE-customer that pays for Vendor-software and
has no money for hardware or operating-system-software AND demands
new features.

(*) I have been bitten by a DR machine that did not have the feature
some 17 years ago- it might be around longer.

[robin]

From: Rob van der Heij
Sent: Monday, 4 June 2012 4:41 PM

>Since most of the time you just new a few more bytes anyway ;-)

?? Doesn't make sense.

[Martin Truebner]

>> ?? Doesn't make sense.

Since most of the time you just NEED a few more bytes anyway

Better now?

[robin]

From: Rob van der Heij
Sent: Monday, 4 June 2012 4:41 PM

Even with the nonsense word changed a la Martin,
your response still doesn't make sense.

[Rob van der Heij]

On Mon, Jun 4, 2012 at 12:20 PM, robin <rob...@dodo.com.au> wrote:

> Even with the nonsense word changed a la Martin,
> your response still doesn't make sense.

Sorry, as Martin noticed my head and fingers had disconnected...
Typically I find the module just slightly extend the 4K after a small
change... 4092 or 4094 is a lot compared to what you need at that
moment. But for future debugging it is much more obvious when the two
base registers are really 4K apart. Seems to me that saving that
single instruction is not worth the trouble.

Rob

[Tony Thigpen]

> I have yet to find that VSE-customer that pays for Vendor-software and
> has no money for hardware or operating-system-software AND demands
> new features.

We have several that meet this requirement. Think about the VSE 2.6 on
P390 ESL boxes.

Tony Thigpen

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

From: Martin Tr�bner
Sent: 06/04/2012 03:27 AM
>>> ... said enough, maybe too much, about this topic
>
> Since the thread is still not dead- here is my point:
>

> Use of relative& immediate feature is the way to go. The time it takes

[McKown, John]

I think it may have been an parody of a joke:
Question: "How much money is enough?"
Answer: "Just a little bit more."

In assembler, it is "how many bytes do you need to be resolvable to a valid offset?" "just a few more."

It's why I (as a customer only), love doing "baseless" programming. I separate the code and data sections, using a base register only for the data section. I load the base register using an LAY (if contained in the same CSECT). I now also use "pure" coding techniques. In this case "pure" means that I never store into the CSECT itself. Actually, I use an RSECT. This is a requirement for writing DLLs in HLASM. Which I have successfully done ("beause I can").

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * www.HealthMarkets.com


Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

> -----Original Message-----
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of robin

> Sent: Monday, June 04, 2012 5:20 AM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: Base registers
>

[Martin Truebner]

Tony,

>> > I have yet to find that VSE-customer that pays for Vendor-software and
> has no money for hardware or operating-system-software AND demands
> new features.
We have several that meet this requirement. Think about the VSE 2.6 on
P390 ESL boxes.

I can imagine customers running that- but asking for new features?

This is like asking for an aircondition in a Ford T.

[Scott Ford]

Martin,

As the say options are like ...everyone had one...your entitled to yours

Scott ford
www.identityforge.com

[Scott Ford]

That was a typo, opinions....our customers usually dictate needs many times

Scott ford
www.identityforge.com

[Scott, Samuel J]

I will be out of the office 6/3 thru 6/11. If you need assistance please call Don Neaves at 817-252-8188 or Darrell Thompson at 817-252-8961. Thanks!

[Scott Ford]

Thanks Gerhard, I feel the same way, especially when you work for a small company and your the only one writing Assembler, with customers asking for changes

Scott ford
www.identityforge.com

On Jun 4, 2012, at 2:49 AM, Gerhard Postpischil <ger...@valley.net> wrote:

> On 6/3/2012 8:52 AM, John Gilmore wrote:
>> Gerhard's point is not so easily dismissed; but 1) it is
>> self-defeating for the technology if pushed very far: it freezes
>> software in a posture that is now more than fifteen years behind the
>> state of the art; and 2) the market for even moderately-priced
>> software among MVT-using hobbyists is very small. Still, seriously
>> pursued dual-path software is is certainly viable.
>
> Supporting obsolete systems is a labor of love; I see no reason
> to impute financial objectives to their support. For example,
> Dave Cole has offered the MVS version of XDC for free, except no
> copy of this version of it has been found.
>

>> As a now certified élitist, I am nevertheless unrepentent. Urgings

[Bill Fairchild]

I have seen many old IBM modules (in dumps, microfiche, etc.) in which the first few instructions are something like this:
MODULE USING *,R15
LR R12,R15
LA R11,4095(,R12)
DROP R15
USING MODULE,R12
USING MODULE+4095,R11
This allows 8,191 bytes of local addressability to be established with only two instructions for a total length of 6 bytes of executable code. This kind of code was "state of the art" long ago when each additional byte of storage was vastly more expensive than that same additional byte is today. Back in those days there was no real storage or virtual storage, just "storage", and modules had to be as small as possible. And many modules written way back then are still alive and well inside z/whatever-its-latest-name-is.
Yes, the odd offsets look weird, but the weird look does not prevent the DAT's ability to add the base register's contents to the displacement and generate the correct address.
When one is writing new code, one is free to be elitist and exploit the latest and greatest instructions that are available on the processors on which the code is expected to run.
When one is working with old code, or even new code written by Luddites, denigrating the technology used does not really help in understanding what the module is doing.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 * e: bfair...@rocketsoftware.com * w: www.rocketsoftware.com

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

Sent: Sunday, June 03, 2012 7:45 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Base registers

[Scott Ford]

Bill,

Amen, I first wrong BAL on a 360/20, didn't have the 1401 exposure ..man half words were real important

Scott ford
www.identityforge.com

[Bodoh John Robert]

The code we use here at my job usually has very large modules and used several base registers. I have seen the following technique used:

MYCSECT CSECT
USING *,R15
B BYID
ID DC C'module-name'
BASES DC A(MYCSECT)
DC A(MYCSECT+4096)
DC A(MYCSECT+2*4096)
DC A(MYCSECT+3*4096)
BYID DS 0H
LM R9,R12,BASES
DROP R15
USING MYCSECT,R9,R10,R11,R12

One CPU instruction to load all base registers. I don't really like dealing with such large programs but I can't do anything about it so I'll support it the way it it.

John

[Dean K. Alston]

Can IT be Trusted on Personal Devices (Nos 9,16,41,50).

Sent via BlackBerry from T-Mobile

[Robert A. Rosenberg]

By replacing the MYCSECT references with BYID+4 you can pick up some
extra free addressability (at the expense of having the offsets
non-zero based).

[Tom Marchant]

Yuck. By adding a few LOCTR instructions, all of the data can be grouped at
the beginning of the program. If relative branches are used in the code,
the base register is needed only for data and literals.

MYCSECT CSECT
USING *,R15
J BYID
DATA LOCTR

ID DC C'module-name'
BASES DC A(MYCSECT)
DC A(MYCSECT+4096)
DC A(MYCSECT+2*4096)
DC A(MYCSECT+3*4096)
BYID DS 0H

CODE LOCTR

LM R9,R12,BASES
DROP R15
USING MYCSECT,R9,R10,R11,R12

...
DATA LOCTR
* additional DC statements are coded here
LTORG

You can probably do with only one base register for the data.

--
Tom Marchant

[McKown, John]

> -----Original Message-----
> From: IBM Mainframe Assembler List

> [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Robert
> A. Rosenberg
> Sent: Monday, June 04, 2012 11:33 PM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: Base registers
>

<snip>

>
> By replacing the MYCSECT references with BYID+4 you can pick up some
> extra free addressability (at the expense of having the offsets
> non-zero based).
>

Back long ago, before I started writing "pure" or "reentrant" code, I would always start my routines:

MYCSECT CSECT
USING *,R15
SAVE (14,12),,*
BAL R1,AROUND
SAVEAREA DC 18A(0)
ST R13,4(,R1)
ST R1,8(,R13)
LR R13,R1
DROP R15
USING SAVEAREA,R13
L R1,4(,R13)
L R1,20(,R1) RESTORE ORIGINAL R1
...

I don't do this any more, in most cases. Just to horrify some of you, I now generally code HLASM enabled code, using all the CEExxx macros.

===

A reason that my manager did not like the above was that if the base register points to the beginning of the CSECT, and you use the SAVE macro properly, you can look at the storage pointed to by the base register to see the "eyecatcher" of the program which abended. The SAVE would usually look something like:

SAVE (14,12),,'&SYSECT &SYSCLOCK'

And he always used base registers in reverse order: R12, R11, R10, and so on.

[McKown, John]

OOPS, the statement:

AROUND DS 0H

should be before the ST R13,4(,R1)

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

[Dan Skomsky @ Home]

Use R14 instead of R1 to avoid the reloading of R1 (parameter list pointer).

We always set the new save are to all X'FF' so it stands out in a DUMP.

[Robert A. Rosenberg]

At 07:57 -0400 on 06/05/2012, Tom Marchant wrote about Re: Base registers:

>Yuck. By adding a few LOCTR instructions, all of the data can be grouped at
>the beginning of the program. If relative branches are used in the code,
>the base register is needed only for data and literals.
>
>MYCSECT CSECT
> USING *,R15
> J BYID
>DATA LOCTR
>ID DC C'module-name'
>BASES DC A(MYCSECT)
> DC A(MYCSECT+4096)
> DC A(MYCSECT+2*4096)
> DC A(MYCSECT+3*4096)
>BYID DS 0H
>CODE LOCTR
> LM R9,R12,BASES
> DROP R15
> USING MYCSECT,R9,R10,R11,R12
>...
>DATA LOCTR
>* additional DC statements are coded here
> LTORG
>
>You can probably do with only one base register for the data.

That BYID needs to be placed after the CODE LOCTR or you will be
jumping into your DATA area and a DC or the LTORG.

[Scott Ford]

Guys,

John and spoke where can you find a good sample of baseless assembler code ?
I want to convert some of ours , need a sample to get me started, it would help...

Scott ford
www.identityforge.com

[Tom Marchant]

Right. Thanks for the correction. The above should be coded as:

>>MYCSECT CSECT
>> USING *,R15
>> J BYID
>>DATA LOCTR
>>ID DC C'module-name'
>>BASES DC A(MYCSECT)
>> DC A(MYCSECT+4096)
>> DC A(MYCSECT+2*4096)
>> DC A(MYCSECT+3*4096)

>>CODE LOCTR
>>BYID DS 0H

>> LM R9,R12,BASES
>> DROP R15
>> USING MYCSECT,R9,R10,R11,R12
>>...
>>DATA LOCTR
>>* additional DC statements are coded here
>> LTORG

--
Tom Marchant

[McKown, John]

Damn, you had to include the word "good". If you want some baseless code which is LE enabled and is designed to run as a z/OS UNIX command, you can download my UNIX "alpha" code from the CBT. It is FILE864 at
http://www.cbttape.org/updates.htm

I also attached a non-LE baseless HLASM program source code to this email. It is a do nothing skeleton. I think the listserv will strip it out.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

> -----Original Message-----
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Scott Ford
> Sent: Tuesday, June 05, 2012 3:00 PM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: Base registers
>

[Tom Marchant]

On Tue, 5 Jun 2012 15:59:36 -0400, Scott Ford wrote:

>where can you find a good sample of baseless assembler code ?

Look for Ed Jaffe's SHARE presentation "Jumpify your code".

"Baseless" is not an accurate description, IMO. You still need
base registers to reference data. You can, however, use very few
base registers for your code simply by using relative branches
("jump"). There are one or two exceptions, depending upon your
hardware. One is that there is no indexed relative branch. It's
hard for me to imagine what such a thing would do anyway. The
other is that EXRL was introduced (IIRC) on the z10. The standard
EXecute instruction requires a base register.

--
Tom Marchant

[Scott Ford]

Tom,
 
Thank you, I have his great presentation and John gave me so code, and who said we old folks cant change....

Scott J Ford
Software Engineer
http://www.identityforge.com
 

________________________________
From: Tom Marchant <m42tom-...@YAHOO.COM>
To: ASSEMBL...@LISTSERV.UGA.EDU
Sent: Tuesday, June 5, 2012 5:19 PM
Subject: Re: Base registers

[Scott Ford]

That should be some code....didnt say my eyes and fingers werent old ...

Scott J Ford
Software Engineer
http://www.identityforge.com
 

________________________________
From: Scott Ford <scott_...@yahoo.com>
To: ASSEMBL...@LISTSERV.UGA.EDU
Sent: Tuesday, June 5, 2012 5:23 PM

[Watkins, Douglas]

Here's one way to do standard EXecute without a base register:

AHI R2,-1 Minus 1 for EX
*!not yetEXRL R2,_EX_MVC_OUTPUT (Move data to output buffer)
LARL R10,_EX_MVC_OUTPUT Move data to
EX R2,0(,R10) output buffer

I believe, for most applications, "baseless" code is the way to go
moving forward when writing new code or refactoring existing code. Of
course, required are bases for save area/local stack and
constants/LTORG. A program manages bases for other data areas, just as
always -- passed-in-by-reference parameters, heap storage, control
blocks, I/O buffers, et cetera. Changing B-s to J-s, BCT to BRCT, et
cetera, is tedious but simple ("change all"). One may encounter macros
(IBM and otherwise) in existing code that, as traditionally used, have
required a base -- there are ways to deal with those.

All in all, I've found this entails a relatively small learning curve
and amount of effort and cures one of the greatest headaches associated
with assembler coding.

Doug Watkins



http://www.compuware.com/
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

From: IBM Mainframe Assembler List
[mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant
Sent: Tuesday, June 05, 2012 5:20 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Base registers

[Paul Gilmartin]

On Jun 6, 2012, at 07:28, Watkins, Douglas wrote:

> Here's one way to do standard EXecute without a base register:
>
> AHI R2,-1 Minus 1 for EX
> *!not yetEXRL R2,_EX_MVC_OUTPUT (Move data to output buffer)
> LARL R10,_EX_MVC_OUTPUT Move data to
> EX R2,0(,R10) output buffer
>

Well, R10 looks like a base register to me. If you're
critically register-constrained, this may be a problem.
You could likewise do:

AHI R2,-1 Minus 1 for EX

BALR R10,0
EX R2,EX_MVC_OUTPUT-*(,R10)

... in fewer bytes of code (if I got it right).

-- gil

[robin]

From: Watkins, Douglas
Sent: Wednesday, 6 June 2012 11:28 PM

>Here's one way to do standard EXecute without a base register:

> AHI R2,-1 Minus 1 for EX

Still need test for negative.

[Watkins, Douglas]

> Still need test for negative.

Very true -- unless, as is the case but not shown in the example below, I've already guaranteed R2 holds a value within my "safe range," which includes the maximum, too.

http://www.compuware.com/
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of robin
Sent: Wednesday, June 06, 2012 11:19 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Base registers

[Watkins, Douglas]

I had a feeling someone would point out that technicality, so...

Let's not consider a temporarily-used-for-one-RX-instruction base
register to be the same thing as a program-wide base register ;-)

Also, a "baseless" program is less likely to be register-constrained;
but, if it were, using "temp" R1 instead of, say R10, works just as
well.

http://www.compuware.com/
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

From: IBM Mainframe Assembler List
[mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin
Sent: Wednesday, June 06, 2012 11:02 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Base registers

[Martin Truebner]

Douglas,

how is this (until EXRL is legalised ;-)

EX R2,=S(7*16+&PACK,DWORD,0(R10))

And Yes- I am aware of problems in the literalpool having
different usings

- (for Robin) and I have verified that R2 is between F and 0 and
that R10 is on the beginning of a string)

[Kirk Talman]

where is the length code for 0(r10) second operand?

EX R2,=S(16*(7+16*(length_of_operand2-1)+&PACK,DWORD,0(R10))

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
06/06/2012 11:46:07 AM:

-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you

[Watkins, Douglas]

Martin,

Very clever! Personally, for everyday use, I prefer things a bit more
"plain and simple." Though, I might consider creating a macro to
incorporate such a technique:
EXWOW R2,(PACK,DWORD,0(R10))
EXWOW R2,(MVC,DESTINATION_BUFFER,0(R10))

The latter being only marginally better than:
EX R2,=S(&MVC,DESTINATION_BUFFER,0(R10))

Of course, one could simply locate the target instruction in with
constant data that is assembled into program object, since that already
has a base. I use LARL with EX because I like to keep the target in the
vicinity of the code with which it belongs logically. I do like that
your technique does keep the essential nature of the target very much
within eyeball range.

Doug

http://www.compuware.com/
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

From: IBM Mainframe Assembler List
[mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Martin Truebner
Sent: Wednesday, June 06, 2012 11:46 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Base registers

[Watkins, Douglas]

Length of second operand is in R2, ORed with that of the first operand,
7*16, when EX executes.

http://www.compuware.com/
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

From: IBM Mainframe Assembler List
[mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Kirk Talman
Sent: Wednesday, June 06, 2012 12:13 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Base registers

[Kirk Talman]

sigh

been away from daily use of ASM. brain is starting to rot.

which is bad as I am transitioning into doing CICS ASM.

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

06/06/2012 01:15:54 PM:

[Jon Perryman]

I suggest you learn how to use LOCTR. It's a much simpler method than using
=S(xxxx) and certainly more readable. I'm not recommending in the way LOCTR was
used with DATA / CODE example although that is certainly one way.

My programs have the following in the program start macro (after the csect is
generated). &CSECT contains the CSECT name since &SYSECT and &SYSLOC are not set
when the CSECT is generated in the macro that generated the CSECT.
#EX LOCTR , Execute instructions inserted with this location
counter
DS 0H Instructions must be halfword aligned
&CSECT LOCTR , Back to program

If you use the DATA / CODE method, then you will want this just before the CODE
LOCTR. I'm not suggesting you use this method but just in case you do.

Here is a sample call to my #EX macro below
#EX R2,'MVC SOURCE(0),DEST'
and it generates (length is checked where length was calculated)
BCTR R2,0 Length relative to 0
EX R2,#EX_xxx Execute the instruction
LA R2,1(R2) Restore length (does not modify CC)
#EX LOCTR ,
#EX_xxx MVC SOURCE(0),DEST
MYPGM LOCTR , Back to program

Hope this helps, Jon.

.******************************************************************
.* Desc: Execute instruction
.*
.* Copyright: 2010-2012 Jon Perryman
.*
.* Function:
.* Makes the length relative to 0 and executes the
.* specified instruction using the specified length.
.* The register is restored back to a length relative
.* to 1.
.*
.* Change log:
.* 2/12/2010 JPP Created
.******************************************************************
MACRO ,
&LABEL #EX &RELATIVE=1 Specify 0 if reg already rel=0

AIF ('&LABEL' EQ '').NOLABEL
&LABEL EQU *
.NOLABEL ANOP *

AIF ('&RELATIVE' EQ '0').LEN_OK1
BCTR &SYSLIST(1),0 Relative to 0
.LEN_OK1 ANOP ,

EX &SYSLIST(1),#EX_&SYSNDX

AIF ('&RELATIVE' EQ '0').LEN_OK2
LA &SYSLIST(1),1(&SYSLIST(1)) Relative to 1
.LEN_OK2 ANOP ,

&WORK SETC DEQUOTE('&SYSLIST(2)')
&WORKN SETA INDEX('&WORK',' ')
&WORK2 SETC '&WORK'(&WORKN+1,99)
&WORK2 SETC DCVAL('&WORK2')
&WORK SETC '&WORK'(1,&WORKN-1)
#EX LOCTR , Group #EX
#EX_&SYSNDX &WORK &WORK2
&SYSLOC LOCTR , Restore location counter


MEXIT ,
MEND ,


-------------------------------------------------------------------------------------------------------------------

On Behalf Of Martin Truebner
Sent: Wednesday, June 06, 2012 11:46 AM

Subject: Re: Base registers

[Martin Truebner]

Jon,

>> I suggest you learn how to use LOCTR.

NO COMMENT

>> It's a much simpler method than using
=S(xxxx) and certainly more readable.

Simpler- maybe! more readable- judge it here:

................................................
My suggestion:

a SETC as intro

and EX R2,=S(&PKA,QWORD,0(R10))

.................................................
or (more readable):

a CODE LOCTR and DEFS LOCTR as intro

and

EX R2,PKA_02
DEFS LOCTR
PKA_02 PKA QWORD,0(0,R10)
CODE LOCTR

plus the extra of inventing unique names

..................................................

I like the expression "in eyeball range" ;-)

[Tuben, Gregg]

Let's not get in a spitting match.
anyone can write bad code as an example of why someone else's style is bad. I am pretty sure I could write some pretty unintelligible code if I tried using any of the suggested methods. That doesn't mean a style is bad, it probably means I am not using it as intended.

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Martin Truebner
Sent: Wednesday, June 06, 2012 11:58 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Base registers

[Binyamin Dissen]

On Wed, 6 Jun 2012 20:57:47 +0200 Martin Truebner <Mar...@pi-sysprog.de>
wrote:


:>>> I suggest you learn how to use LOCTR.

:>NO COMMENT

It is good advice.

:>>> It's a much simpler method than using

:>=S(xxxx) and certainly more readable.

:>Simpler- maybe! more readable- judge it here:

:>................................................
:>My suggestion:

:>a SETC as intro

:>and EX R2,=S(&PKA,QWORD,0(R10))

:>.................................................
:>or (more readable):

:>a CODE LOCTR and DEFS LOCTR as intro

:>and

:> EX R2,PKA_02
:>DEFS LOCTR
:>PKA_02 PKA QWORD,0(0,R10)
:>CODE LOCTR

I have a @DC macro as well as an @EX macro to allow the constants to be placed
in the source file near the code that uses it and the assembler neatly
packages all the constant data (including the EXed instructions) together.

Isn't

@EX R2,PKA,QSWORD,0(0,R10)

clearer?

--
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.

[Edward Jaffe]

On 6/2/2012 5:38 PM, Tony Thigpen wrote:
> > but there is none to be made for doing so in
> > writing even a new single RSECT.
>
> How about this reason.
>
> We have several customers running our software that are on pre-MP3000
> machines that don't even support relative instructions. They still pay
> us for support and that includes software upgrades.
>
> Other vendors may not care about existing customers, but we do.
>
> Almost all of these customers also can't upgrade their VSE. They fell
> into the ESL trap with IBM many years ago and now can't get their budget
> dollars back to get current because of the IBM monthly charges. As
> faithful customers for many years, we do not want to kick them while
> they are down just so we can do 'fancier' code.

There are two sides to this. You need to care about all of your customers, not
just those with no money. Dragging premier customers, with the latest hardware
and software, down to the level of the laggards is not fair to them. Customers
that continue to invest heavily in the platform must be rewarded for doing so.
IBM and ISV software should exploit the latest hardware and software features in
ways that provide these leading edge customers with the very best performance
and feature set possible lest they find an alternative (seemingly cheaper) way
to host their applications.

It's not just 'fancier' code. The productivity gains accrued by allowing
programmers to leverage new facilities are immense; new features can be
implemented in far less time giving customers more of they want for their
maintenance dollars; tremendous run-time performance savings can be realized by
leveraging new hardware and software features; today's memory rich (especially)
64-bit environments allow programs to do things only dreamed of twenty years
ago; and, so on...

The ESL problem is a unique problem for VSE that does not exist for MVS
customers. Nevertheless, the reality is that very, Very, VERY few customers
running severely back-level operating system releases are interested in
installing the latest and greatest release of 'Product X' -- even on VSE. Often,
such systems exist because the customer is in their 15th year of their 3-year
plan to migrate off the mainframe.

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

[Edward Jaffe]

On 6/5/2012 2:19 PM, Tom Marchant wrote:
> On Tue, 5 Jun 2012 15:59:36 -0400, Scott Ford wrote:
>
>> where can you find a good sample of baseless assembler code ?
> Look for Ed Jaffe's SHARE presentation "Jumpify your code".

The original "jumpify your code" presentation was from 2007. When I updated it
in 2011 for zEnterprise, I retitled it "jumpify your programs".

I *knew* I should have kept the original title! >:o

[John Gilmore]

ISVs that have many VSE customers confront a special problem. If they
judge it morally and/or economically appropriate to continue to
support the ESL-trapped among these VSE customers they should do so by
providing two code paths. To do this is a trivial and inexpensive,
even in open code, as Tony Thigpen knows very well.

I think that Edward Jaffe has this morning made the case for the use
of the new instructions about as well as it can be made; and I will
not therefore revisit it except to note that support for ARCH
(<level>)-driven multiple code paths, which can be packaged up into
reusable macros readily (and could even be introduced into the
structured-programming macro package) is the appropriate resolution
of any need to support very different hardware groups concurrently; a
much better one than the systematic use of LCD technology that Tony,
if I have understood his views correctly, is advocating.

John Gilmore, Ashland, MA 01721 - USA

[Scott Ford]

John,

Can't comment on VSE , we don't have any VSE customers, our customers are z/OS only.
I not sure what ESL is, I assume it's a pricing plan from IBM for VSE, haven't worked VSE in yrs

Scott ford
www.identityforge.com

[John Gilmore]

'Jumpify your code' suggests to me that we should perhaps replace
'baseless', which in ordinary English means 'unfounded', with the
acronym JBC, for 'Jump-based code'.

[Scott Ford]

Ed,

I saw your 2007 presentation and have a copy. I am always looking for good examples to aid my education and understanding.


Regards,

Scott ford
www.identityforge.com

[Paul Gilmartin]

On Jun 16, 2012, at 14:10, John Gilmore wrote:

> 'Jumpify your code' suggests to me that we should perhaps replace
> 'baseless', which in ordinary English means 'unfounded', with the
> acronym JBC, for 'Jump-based code'.
>

No need. There are many instances where English accepts
specialized meanings for words in special contexts which
don't directly contradict each other, and of which some
may even become pejorative. The first example that comes
to my mind is "vulgar", as in "The vulgar meaning of
'baseless' is 'unfounded'."

-- gil

[John Gilmore]

Words can of course have different specialized meanings in different
contexts, but there is ordinarily an evolutionary path between these
meanings.

Physicians, for example, talk of "senile changes", meaning those
associated with aging, in a way that is entirely devoid of pejorative
intent. Or again, Chaucer and his contemporaries used the word "lewd"
to mean lay, not in holy orders; but there is a path between this
meaning and the modern one: the clergy did not often make what we call
lewd gestures in public.

I myself find 'baseless' very unsatisfactory, in part because it is
not at all transparent. Thus, while I have no emotional investment in
the term "jump-based", I do believe a new one is needed; 'baseless'
can scarcely avoid connotations of dispensability when in fact it is
the base registers that are largely dispensable.

We need to look forward to a time when the use of base registers,
multiple ones in particular, and the arbitrary segmentation of code
into 4096-byte pieces will be perceived as a quaint, historically
interesting but obsolete practices; and a new contrasting term will be
helpful in changing the current "vulgar" mind set. (Mr Gilmartin's
use of vulgar, which evolved from the Latin phrase "mobile vulgus", is
open to criticism; but that is a subject for another time and place.)

Alternative suggestions?

[Edward Jaffe]

On 6/16/2012 2:54 PM, Scott Ford wrote:
> I saw your 2007 presentation and have a copy. I am always looking for good examples to aid my education and understanding.

For those having trouble finding the February 2011 version of this presentation
on SHARE's new web site, here is a link to it on the Phoenix Software site:
ftp://ftp.phoenixsoftware.com/pub/demo/Jumpify_Your_Code_2011.pdf

[Martin Truebner]

Ed,

can I link to yours from mine?

http://pi-sysprog.de/free/makerel.html

or (in another language)

http://pi-sysprog.de/free/makereld.html

on the very end

[Edward Jaffe]

On 6/17/2012 9:13 AM, Martin Truebner wrote:
> Ed,
>
> can I link to yours from mine?
>
> http://pi-sysprog.de/free/makerel.html
>
> or (in another language)
>
> http://pi-sysprog.de/free/makereld.html
>
> on the very end

Of course! 8-)

Your bilingual perspective (I mean VSE/MVS, not English/German ;-) ) is always
highly appreciated!

[Gerhard Postpischil]

On 6/17/2012 9:05 AM, John Gilmore wrote:
> Words can of course have different specialized meanings in different
> contexts, but there is ordinarily an evolutionary path between these
> meanings.

My favorite along these lines is "stench", that did not always
mean unpleasant. I vividly remember a streetcar ride where
almost every passenger carried freshly cut lilacs, to the point
where the smell was overpowering, though not unpleasant.

> Alternative suggestions?

I used "unbased".

Gerhard Postpischil
Bradford, VT

[John Gilmore]

Unbased is better by a wide margin than baseless.

I should still, however, prefer a non-negative form.

John Gilmore, Ashland, MA 01721 - USA

[Gord Tomlin]

Why don't we "jump" to the underlying notion of the "jump" instructions,
or more accurately "branch relative" instructions, which is relative
addressing: "relative address oriented programming".

I'll admit that it's not concise, but I'm optimistic we won't have a
religious war about the resulting acronym.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

[Steve Comstock]

On 6/17/2012 3:13 PM, Gord Tomlin wrote:
> Why don't we "jump" to the underlying notion of the "jump" instructions,
> or more accurately "branch relative" instructions, which is relative
> addressing: "relative address oriented programming".
>
> I'll admit that it's not concise, but I'm optimistic we won't have a
> religious war about the resulting acronym.

You mean "Religious Argument Ontological Parsing"? :-)

I was going to suggest 'free base' as a 'positive' way
of saying one is relatively free from using base registers,
but that term also has unfortunate conotations.

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html

[J R]

The problem is that all addresses are relative to something.
Some are relative to a base register, some are relative
to the current instruction. Even absolute addresses are
relative to zero. ;-)

How about base-free code? That sounds like a positive thing.

(I avoided the temptation to to suggest "freebase" lest that
be considered to have a negative connotation.)

===

> Date: Sun, 17 Jun 2012 17:13:30 -0400
> From: gt.ibm...@actionsoftware.com
> Subject: Re: Base registers
> To: ASSEMBL...@LISTSERV.UGA.EDU

[J R]

Sorry Steve. I didn't see your post until after I posted mine.

===

> Date: Sun, 17 Jun 2012 17:35:36 -0400
> From: jaya...@hotmail.com

[Hobart Spitz]

Just my two cents:

1. There are architectures which have always had relative addressing,
and use that term.
2. Some day, relative braches will be the norm and not the exception.
As time goes on, any term with "base" as the root (e.g. unbased, baseless,
etc.) is likely to need increasingly superfluous explanations to novices.

Thus, I suggest "relative branch" and/or "jump" should suffice. For the
exclusive case (non-base register branching) perhaps "relative-only
branching" and/or "jump-only" program[ming].

--
OREXXMan

[Robin Vowels]

From: "Watkins, Douglas" <Douglas...@compuware.com>
Sent: Wednesday, 6 June 2012 11:28 PM


> Here's one way to do standard EXecute without a base register:
>
> AHI R2,-1 Minus 1 for EX

BTW,
BCTR 2,0 will do a better job.

[John McKown]

I agree. It is two bytes shorter. Possibly faster. Does not disturb the
condition code. And is a generally understood standard notation. Might
even be considered like the DECrement instruction in other assemblers.

As an aside, I was actually (foolishly) considering making macros called
DEC (as in DEC Reg,Value => AHI Reg,0-&Value with default of 1), INC
(INC Reg,Value => AHI Reg,Value, default of 1), PRED Reg (DEC Reg,1),
SUCC Reg (INC Reg). Then realized it would likely be more confusing than
helpful.

--
John McKown
Maranatha! <><

[Gerhard Postpischil]

On 6/17/2012 10:44 PM, John McKown wrote:
> As an aside, I was actually (foolishly) considering making macros called
> DEC (as in DEC Reg,Value => AHI Reg,0-&Value with default of 1), INC
> (INC Reg,Value => AHI Reg,Value, default of 1), PRED Reg (DEC Reg,1),
> SUCC Reg (INC Reg). Then realized it would likely be more confusing than
> helpful.

Not sure what's confusing about it; I've had an INC for ages (no
DEC, instead put INC=-1 on INC - that may be confusing?). It
changes either a register or storage, and had a version for
halfwords named INCH <g>

Gerhard Postpischil
Bradford, VT

[Rob van der Heij]

On Mon, Jun 18, 2012 at 6:52 AM, Gerhard Postpischil <ger...@valley.net> wrote:

> Not sure what's confusing about it; I've had an INC for ages (no
> DEC, instead put INC=-1 on INC - that may be confusing?). It
> changes either a register or storage, and had a version for
> halfwords named INCH <g>

Yep! It's a ver useful way to abstract from the actual implementation.
It helps distinguish the BCTR x,0 from the ones that implement a loop.

Since I have *no* branch instructions or labels in my new code other
than generated by structured programming macros, going to basefree
code will only take changes to the macros. A BCTR would stand out more
than I want.

Rob

[Binyamin Dissen]

On Mon, 18 Jun 2012 11:24:14 +1000 Robin Vowels <rob...@dodo.com.au> wrote:

:>From: "Watkins, Douglas" <Douglas...@compuware.com>

Unless you place a JM after the AHI

[Thomas Berg]

All your bases are belong to us ?



Regards,
Thomas Berg
_______________________________________________________
Thomas Berg Specialist AM/SM&S SWEDBANK AB (publ)



> -----Ursprungligt meddelande-----
> Fr�n: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> LI...@LISTSERV.UGA.EDU] F�r John Gilmore
> Skickat: den 17 juni 2012 23:01
> Till: ASSEMBL...@LISTSERV.UGA.EDU
> �mne: Re: Base registers

[Fred van der Windt]

> All your bases are belong to us ?

For great justice.

Fred!
-----------------------------------------------------------------
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.
-----------------------------------------------------------------

[Rob van der Heij]

On Mon, Jun 18, 2012 at 10:36 AM, Thomas Berg <thoma...@swedbank.se> wrote:

> All your bases are belong to us ?

LOL. Just when I was convinced we had cross-talk with the IBM-MAIN list ;-)

May the source be with you...