Re: ASMA034E

2018-11-16 Thread Seymour J Metz
The whole point of assembler is making it easier for the programmer to code, as 
with any other language. Yes, use of macro instructions removes some of the  
tight control of the generated machine code, but that is a good thing. I've 
programmed in assemblers with no macro facility, and they just make for more 
work. As an example, I've written code that expands to, e.g., a L/LA for a 
S/360 and an XR/ICM for a S/370; much easier than maintaining two different 
versions and much more efficient than avoiding the new instructions.


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


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Thursday, November 15, 2018 11:33 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: ASMA034E

@Greg is right -- Jump is not a big learning curve with lots of gotchas (unlike 
say 64-bit or AR mode).

In addition to replacing Bxx with Jxx, you need to replace BAL with BRAS. 
Again, works exactly the same, one-for-one, but no base register needed.

LARL is also very cool. It is like LA without a base register. If you code LA 
R1,FOO you first need a base register pointing to FOO (assuming FOO is not a 
numeric constant). If you code LARL R1,FOO you do not.

I am personally not fond of IEABRCX. The whole point of assembler is tight 
control of the generated machine code; not compiler magic. It is not hard at 
all to do CHG B J PREFIX and work through them one at a time either accepting 
each proposed change or finding the next. Or CHG BE JE WORD and work through 
all of the BH, BL, BNE and so forth. Anything you miss is easy to find: you'll 
get an addressability error message from the assembler.

I am not absolutely positive -- I fixed my problem and moved on -- but I 
*think* IEACBRCX fouled up the LE entry macro EDCPRLG. I *think* something in 
LE was expecting to see a 47 opcode specifically.

I also prefer the use of LOCTR to LARL Rn,STATIC but different strokes for 
different folks.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Price
Sent: Thursday, November 15, 2018 7:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASMA034E

On 2018-11-16 1:47 AM, Ward Able, Grant wrote:
> Can someone point me to a reasonably simple example?

If you can do branch instructions then you can do branch-relative
instructions. Apart from RR instructions (BR, BASR, BALR, BASSM, BSM,
BAKR and any others I've missed) replace the B that starts the branch
instruction mnemonic with BR, or as I prefer to do, with J (for jump).

eg. BNH -> JNH and BCT -> JCT and BAS -> JAS etc.

Put all the stuff which needs to be cover by a base register after all
the instructions, and start the area with a label, and "use" that.

eg.
LARL R11,Static
USING Static,R11
...

Static DC 0D  My module's constants and literals and non-RENT variables


Then all you need to cover is code generated by macros, which is why
Peter mentioned ARCHLVL (look up the SYSSTATE macro) to cover macros
with logic to test it, and the IEABRCX macro to cover the rest.

IEABRCX DEFINE
will define and activate the facility where the older "branch"
instructions will be converted to newer "branch relative" instructions
when encountered by the assembler in the source code.  With IEABRCX you
could even leave the old branch source code as-is, but personally I
prefer to use the newer mnemonics to make it obvious that the code is
probably not covered by a base register, and to keep the listing a bit
tidier.

IEABRCX is "better" than IEABRC because you can turn it on and off as
needed. The most well known scenario where you might was to turn it off
(I'd say) is if you have a branch table where you use the index register
of the branch-on-condition instruction to provide an index into a table
of branch (or even jump) instructions.

That's probably enough to get you started.  Have fun with it.

Cheers,
Greg P.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-16 Thread Binyamin Dissen
On Fri, 16 Nov 2018 08:17:32 -0500 Peter Relson  wrote:

:>
:>So where you have a problem with what is generated, turn off IEABRCX. 
:>

:>Just curious: do you have an example where IEABRCX resulted in the wrong 
:>thing?

I would guess an assembly error when the target address is not in the current
CSECT but addressed by a USING.

:>We tend to use IEABRC/IEABRCX to cover macro invocations, but also do 
:>change our own branches to relative branches (as pointed out, this is 
:>usually a pretty quick edit) since it makes the listing cleaner.

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-16 Thread Peter Relson

So where you have a problem with what is generated, turn off IEABRCX. 


Just curious: do you have an example where IEABRCX resulted in the wrong 
thing?

We tend to use IEABRC/IEABRCX to cover macro invocations, but also do 
change our own branches to relative branches (as pointed out, this is 
usually a pretty quick edit) since it makes the listing cleaner.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Paul Gilmartin
On Thu, 15 Nov 2018 22:22:31 -0500, Gord Tomlin wrote:

>On 2018-11-15 16:43, Tom Marchant wrote:
>> I believe that you can have a relative branch to a symbol in another
>> CSECT that is resolved at binder time.
>
>Yes, if you include GOFF in your HLASM parameters. You will find that
>when you specify GOFF, you will also need LIST(133) .
> 
Wouldn't you think it would be able to figure that out for itself?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Gord Tomlin

On 2018-11-15 16:43, Tom Marchant wrote:

I believe that you can have a relative branch to a symbol in another
CSECT that is resolved at binder time.


Yes, if you include GOFF in your HLASM parameters. You will find that 
when you specify GOFF, you will also need LIST(133) .


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Charles Mills
Just habit. Just what I do.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Thursday, November 15, 2018 3:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASMA034E

A nitpick, but why would you change everything to Jxx except BAL/BAS?  JAS
would be more consistent.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Charles Mills
AFAIK. Did you try?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, November 15, 2018 3:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASMA034E

On Thu, 15 Nov 2018 15:43:12 -0600, Tom Marchant wrote:
>
>>If the programmer is so rash as to define an ENTRY point with an odd
>>address, Bad Things can happen.
>
>I don't think that HLASM will allow you to do that.
>
How about:
FRED CSECT
 DCC'A'
JOE  DCC'Data only; not executable.'
 ENTRY JOE
 END

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Steve Smith
A nitpick, but why would you change everything to Jxx except BAL/BAS?  JAS
would be more consistent.

IEABRC is pretty clever, but I've found it pretty quick to just rename all
the B* to J* and clean up the exceptions.

However, in my recent environment, virtually no branches of any kind were
hard-coded; only some macro maintenance was needed.

sas

On Thu, Nov 15, 2018 at 11:34 AM Charles Mills  wrote:

> @Greg is right -- Jump is not a big learning curve with lots of gotchas
> (unlike say 64-bit or AR mode).
>
> In addition to replacing Bxx with Jxx, you need to replace BAL with BRAS.
> Again, works exactly the same, one-for-one, but no base register needed.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Paul Gilmartin
On Thu, 15 Nov 2018 15:43:12 -0600, Tom Marchant wrote:
>
>>If the programmer is so rash as to define an ENTRY point with an odd
>>address, Bad Things can happen.
>
>I don't think that HLASM will allow you to do that.
>
How about:
FRED CSECT
 DCC'A'
JOE  DCC'Data only; not executable.'
 ENTRY JOE
 END

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Charles Mills
> I believe that you can have a relative branch to a symbol in another 
> CSECT that is resolved at binder time.

You can but you need the enhanced object code format to do that. GOFF? Some 
such thing.

>If the programmer is so rash as to define an ENTRY point with an odd
>address, Bad Things can happen.

I am pretty certain HLASM will let you do that, and there is nothing inherently 
wrong with that. It is not a Bad Thing. (Arguably bad programming style, but 
not bad technology if you will). Instructions of course cannot be on an odd 
boundary, so an instruction-type entry point also cannot. That is an 
instruction issue. An entry can be odd, provided it is a variable or constant. 
AFAIK HLASM fully supports.

I once played with absolute entry points, but I have forgotten the outcome. The 
idea was that a "parameter" or customization type module might contain BUFFLEN 
EQU 5000/ENTRY BUFFLEN. Then in a functional module one might code L 
R0,=A(BUFFLEN)/GETMAIN ...

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, November 15, 2018 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASMA034E

On Thu, 15 Nov 2018 13:21:01 -0600, Paul Gilmartin wrote:

>On Thu, 15 Nov 2018 12:38:05 -0600, Tom Marchant wrote:
>
>>On Thu, 15 Nov 2018 08:33:55 -0800, Charles Mills wrote:
>>
>>>LARL is also very cool. It is like LA without a base register.
>>
>>Agreed. One thing to be aware of with LARL. It uses a signed 
>>halfword that is added to the current PSW address. As a result 
>>it cannot be used to get the address of an odd address. ...
>> 
>I believe the stumbling block is not the signedness but that the
>displacement is multiplied by 2 in order to double the reach.

Right. The fact that it is signed allows references forward or backward. 
I neglected to say that the signed offset is in halfwords, and so it is 
multiplied by 2. Thanks for the correction.
>
>>... Nor can it be used to get an address in a DSECT, or in a CSECT that 
>>is not part of the same load module.
>>  
>The requires using the result from STORAGE; the latter a V-constant.
>
>Is Binder nowadays savvy to RL displacements to honor RLD entries?

I believe that you can have a relative branch to a symbol in another 
CSECT that is resolved at binder time. I'm not sure if that is what you 
mean. I haven't used it, so I'm not writing this from experience.

>If the programmer is so rash as to define an ENTRY point with an odd
>address, Bad Things can happen.

I don't think that HLASM will allow you to do that.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Tom Marchant
On Thu, 15 Nov 2018 13:21:01 -0600, Paul Gilmartin wrote:

>On Thu, 15 Nov 2018 12:38:05 -0600, Tom Marchant wrote:
>
>>On Thu, 15 Nov 2018 08:33:55 -0800, Charles Mills wrote:
>>
>>>LARL is also very cool. It is like LA without a base register.
>>
>>Agreed. One thing to be aware of with LARL. It uses a signed 
>>halfword that is added to the current PSW address. As a result 
>>it cannot be used to get the address of an odd address. ...
>> 
>I believe the stumbling block is not the signedness but that the
>displacement is multiplied by 2 in order to double the reach.

Right. The fact that it is signed allows references forward or backward. 
I neglected to say that the signed offset is in halfwords, and so it is 
multiplied by 2. Thanks for the correction.
>
>>... Nor can it be used to get an address in a DSECT, or in a CSECT that 
>>is not part of the same load module.
>>  
>The requires using the result from STORAGE; the latter a V-constant.
>
>Is Binder nowadays savvy to RL displacements to honor RLD entries?

I believe that you can have a relative branch to a symbol in another 
CSECT that is resolved at binder time. I'm not sure if that is what you 
mean. I haven't used it, so I'm not writing this from experience.

>If the programmer is so rash as to define an ENTRY point with an odd
>address, Bad Things can happen.

I don't think that HLASM will allow you to do that.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Paul Gilmartin
On Thu, 15 Nov 2018 12:38:05 -0600, Tom Marchant wrote:

>On Thu, 15 Nov 2018 08:33:55 -0800, Charles Mills wrote:
>
>>LARL is also very cool. It is like LA without a base register.
>
>Agreed. One thing to be aware of with LARL. It uses a signed 
>halfword that is added to the current PSW address. As a result 
>it cannot be used to get the address of an odd address. ...
> 
I believe the stumbling block is not the signedness but that the
displacement is multiplied by 2 in order to double the reach.

>... Nor can it be used to get an address in a DSECT, or in a CSECT that 
>is not part of the same load module.
>  
The requires using the result from STORAGE; the latter a V-constant.

Is Binder nowadays savvy to RL displacements to honor RLD entries?

If the programmer is so rash as to define an ENTRY point with an odd
address, Bad Things can happen.

>There are still situations where LA is appropriate.
>
>There is no need to change every Branch instruction to Branch 
>Relative (Jump) in order to start using relative instructions. If you 
>are changing an existing program you can code any new branches 
>as branch relative, except for the situation where you want to use 
>an indexed branch.
> 
A compiler can make the choice of format to use to minimize I-fetch
bandwidth.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Tom Marchant
On Thu, 15 Nov 2018 08:33:55 -0800, Charles Mills wrote:

>LARL is also very cool. It is like LA without a base register.

Agreed. One thing to be aware of with LARL. It uses a signed 
halfword that is added to the current PSW address. As a result 
it cannot be used to get the address of an odd address. Nor 
can it be used to get an address in a DSECT, or in a CSECT that 
is not part of the same load module.

There are still situations where LA is appropriate.

There is no need to change every Branch instruction to Branch 
Relative (Jump) in order to start using relative instructions. If you 
are changing an existing program you can code any new branches 
as branch relative, except for the situation where you want to use 
an indexed branch.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Steve Thompson
So where you have a problem with what is generated, turn off IEABRCX. Then turn 
it back on. The documentation explains this.

The macro could only have so much smarts. 

Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct 
mistaks 


> On Nov 15, 2018, at 11:33 AM, Charles Mills  wrote:
> 
> @Greg is right -- Jump is not a big learning curve with lots of gotchas 
> (unlike say 64-bit or AR mode).
> 
> In addition to replacing Bxx with Jxx, you need to replace BAL with BRAS. 
> Again, works exactly the same, one-for-one, but no base register needed.
> 
> LARL is also very cool. It is like LA without a base register. If you code LA 
> R1,FOO you first need a base register pointing to FOO (assuming FOO is not a 
> numeric constant). If you code LARL R1,FOO you do not.
> 
> I am personally not fond of IEABRCX. The whole point of assembler is tight 
> control of the generated machine code; not compiler magic. It is not hard at 
> all to do CHG B J PREFIX and work through them one at a time either accepting 
> each proposed change or finding the next. Or CHG BE JE WORD and work through 
> all of the BH, BL, BNE and so forth. Anything you miss is easy to find: 
> you'll get an addressability error message from the assembler. 
> 
> I am not absolutely positive -- I fixed my problem and moved on -- but I 
> *think* IEACBRCX fouled up the LE entry macro EDCPRLG. I *think* something in 
> LE was expecting to see a 47 opcode specifically.
> 
> I also prefer the use of LOCTR to LARL Rn,STATIC but different strokes for 
> different folks.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Greg Price
> Sent: Thursday, November 15, 2018 7:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ASMA034E
> 
>> On 2018-11-16 1:47 AM, Ward Able, Grant wrote:
>> Can someone point me to a reasonably simple example?
> 
> If you can do branch instructions then you can do branch-relative 
> instructions. Apart from RR instructions (BR, BASR, BALR, BASSM, BSM, 
> BAKR and any others I've missed) replace the B that starts the branch 
> instruction mnemonic with BR, or as I prefer to do, with J (for jump).
> 
> eg. BNH -> JNH and BCT -> JCT and BAS -> JAS etc.
> 
> Put all the stuff which needs to be cover by a base register after all 
> the instructions, and start the area with a label, and "use" that.
> 
> eg.
> LARL R11,Static
> USING Static,R11
> ...
> 
> Static DC 0D  My module's constants and literals and non-RENT variables
> 
> 
> Then all you need to cover is code generated by macros, which is why 
> Peter mentioned ARCHLVL (look up the SYSSTATE macro) to cover macros 
> with logic to test it, and the IEABRCX macro to cover the rest.
> 
> IEABRCX DEFINE
> will define and activate the facility where the older "branch" 
> instructions will be converted to newer "branch relative" instructions 
> when encountered by the assembler in the source code.  With IEABRCX you 
> could even leave the old branch source code as-is, but personally I 
> prefer to use the newer mnemonics to make it obvious that the code is 
> probably not covered by a base register, and to keep the listing a bit 
> tidier.
> 
> IEABRCX is "better" than IEABRC because you can turn it on and off as 
> needed. The most well known scenario where you might was to turn it off 
> (I'd say) is if you have a branch table where you use the index register 
> of the branch-on-condition instruction to provide an index into a table 
> of branch (or even jump) instructions.
> 
> That's probably enough to get you started.  Have fun with it.
> 
> Cheers,
> Greg P.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Ward Able, Grant
Thanks a lot Greg. I am sure to have fun with that!

Regards – Grant



DTCC Internal (Green)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Price
Sent: 15 November 2018 15:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASMA034E

ATTENTION! This email originated outside of DTCC; exercise caution.


On 2018-11-16 1:47 AM, Ward Able, Grant wrote:
> Can someone point me to a reasonably simple example?

If you can do branch instructions then you can do branch-relative instructions. 
Apart from RR instructions (BR, BASR, BALR, BASSM, BSM, BAKR and any others 
I've missed) replace the B that starts the branch instruction mnemonic with BR, 
or as I prefer to do, with J (for jump).

eg. BNH -> JNH and BCT -> JCT and BAS -> JAS etc.

Put all the stuff which needs to be cover by a base register after all the 
instructions, and start the area with a label, and "use" that.

eg.
LARL R11,Static
USING Static,R11
...

Static DC 0D  My module's constants and literals and non-RENT variables


Then all you need to cover is code generated by macros, which is why Peter 
mentioned ARCHLVL (look up the SYSSTATE macro) to cover macros with logic to 
test it, and the IEABRCX macro to cover the rest.

IEABRCX DEFINE
will define and activate the facility where the older "branch"
instructions will be converted to newer "branch relative" instructions when 
encountered by the assembler in the source code.  With IEABRCX you could even 
leave the old branch source code as-is, but personally I prefer to use the 
newer mnemonics to make it obvious that the code is probably not covered by a 
base register, and to keep the listing a bit tidier.

IEABRCX is "better" than IEABRC because you can turn it on and off as needed. 
The most well known scenario where you might was to turn it off (I'd say) is if 
you have a branch table where you use the index register of the 
branch-on-condition instruction to provide an index into a table of branch (or 
even jump) instructions.

That's probably enough to get you started.  Have fun with it.

Cheers,
Greg P.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DTCC DISCLAIMER: This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error, please notify us 
immediately and delete the email and any attachments from your system. The 
recipient should check this email and any attachments for the presence of 
viruses.  The company accepts no liability for any damage caused by any virus 
transmitted by this email.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Pew, Curtis G
On Nov 15, 2018, at 10:33 AM, Charles Mills  wrote:
> 
> I am personally not fond of IEABRCX. The whole point of assembler is tight 
> control of the generated machine code; not compiler magic. It is not hard at 
> all to do CHG B J PREFIX and work through them one at a time either accepting 
> each proposed change or finding the next. Or CHG BE JE WORD and work through 
> all of the BH, BL, BNE and so forth. Anything you miss is easy to find: 
> you'll get an addressability error message from the assembler. 
> 

I would always use Jxx in code I write myself, but IEABRCX is useful if you’re 
using older macros that haven’t been updated to take ARCHLVL into account.


-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Charles Mills
Or you can just put CODE LOCTR before your entry point instruction.

Here is the slightly edited beginning of one of my modules. This gets the 
copyright constant first in the object code, and avoids any extra branches. 
(ABEND EDCPRLG is an entry point.)

CZ4MIA$L CSECT
 SYSSTATE ARCHLVL=2,OSREL=ZOSV1R6V1R9 makes no difference?
DATA LOCTR ,
 DCC'Copyright 2010, 2015, 2016 CorreLog Inc.'
CODE LOCTR ,
ABENDEDCPRLG DSALEN=CDSALEN,BASEREG=NONE  
 LARL  R12,CZ4MIA$L
 USING CZ4MIA$L,R12
 Etc.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, November 15, 2018 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASMA034E

On Fri, 16 Nov 2018 02:17:47 +1100, Greg Price wrote:

>On 2018-11-16 1:47 AM, Ward Able, Grant wrote:
>> Can someone point me to a reasonably simple example?
>
>If you can do branch instructions then you can do branch-relative
>instructions. Apart from RR instructions (BR, BASR, BALR, BASSM, BSM,
>BAKR and any others I've missed) replace the B that starts the branch
>instruction mnemonic with BR, or as I prefer to do, with J (for jump).
>
>eg. BNH -> JNH and BCT -> JCT and BAS -> JAS etc.

The only thing that you can't do is an indexed branch, where you use a 
base register and an index register.

>Put all the stuff which needs to be cover by a base register after all
>the instructions, and start the area with a label, and "use" that.

That's one way to do it. Another is to consolidate all the constants at the 
beginning of the program using LOCTR. For example, like this:

PROGNAME J START
DATA LOCTR

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Charles Mills
@Greg is right -- Jump is not a big learning curve with lots of gotchas (unlike 
say 64-bit or AR mode).

In addition to replacing Bxx with Jxx, you need to replace BAL with BRAS. 
Again, works exactly the same, one-for-one, but no base register needed.

LARL is also very cool. It is like LA without a base register. If you code LA 
R1,FOO you first need a base register pointing to FOO (assuming FOO is not a 
numeric constant). If you code LARL R1,FOO you do not.

I am personally not fond of IEABRCX. The whole point of assembler is tight 
control of the generated machine code; not compiler magic. It is not hard at 
all to do CHG B J PREFIX and work through them one at a time either accepting 
each proposed change or finding the next. Or CHG BE JE WORD and work through 
all of the BH, BL, BNE and so forth. Anything you miss is easy to find: you'll 
get an addressability error message from the assembler. 

I am not absolutely positive -- I fixed my problem and moved on -- but I 
*think* IEACBRCX fouled up the LE entry macro EDCPRLG. I *think* something in 
LE was expecting to see a 47 opcode specifically.

I also prefer the use of LOCTR to LARL Rn,STATIC but different strokes for 
different folks.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Price
Sent: Thursday, November 15, 2018 7:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASMA034E

On 2018-11-16 1:47 AM, Ward Able, Grant wrote:
> Can someone point me to a reasonably simple example?

If you can do branch instructions then you can do branch-relative 
instructions. Apart from RR instructions (BR, BASR, BALR, BASSM, BSM, 
BAKR and any others I've missed) replace the B that starts the branch 
instruction mnemonic with BR, or as I prefer to do, with J (for jump).

eg. BNH -> JNH and BCT -> JCT and BAS -> JAS etc.

Put all the stuff which needs to be cover by a base register after all 
the instructions, and start the area with a label, and "use" that.

eg.
LARL R11,Static
USING Static,R11
...

Static DC 0D  My module's constants and literals and non-RENT variables


Then all you need to cover is code generated by macros, which is why 
Peter mentioned ARCHLVL (look up the SYSSTATE macro) to cover macros 
with logic to test it, and the IEABRCX macro to cover the rest.

IEABRCX DEFINE
will define and activate the facility where the older "branch" 
instructions will be converted to newer "branch relative" instructions 
when encountered by the assembler in the source code.  With IEABRCX you 
could even leave the old branch source code as-is, but personally I 
prefer to use the newer mnemonics to make it obvious that the code is 
probably not covered by a base register, and to keep the listing a bit 
tidier.

IEABRCX is "better" than IEABRC because you can turn it on and off as 
needed. The most well known scenario where you might was to turn it off 
(I'd say) is if you have a branch table where you use the index register 
of the branch-on-condition instruction to provide an index into a table 
of branch (or even jump) instructions.

That's probably enough to get you started.  Have fun with it.

Cheers,
Greg P.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Tom Marchant
On Fri, 16 Nov 2018 02:17:47 +1100, Greg Price wrote:

>On 2018-11-16 1:47 AM, Ward Able, Grant wrote:
>> Can someone point me to a reasonably simple example?
>
>If you can do branch instructions then you can do branch-relative
>instructions. Apart from RR instructions (BR, BASR, BALR, BASSM, BSM,
>BAKR and any others I've missed) replace the B that starts the branch
>instruction mnemonic with BR, or as I prefer to do, with J (for jump).
>
>eg. BNH -> JNH and BCT -> JCT and BAS -> JAS etc.

The only thing that you can't do is an indexed branch, where you use a 
base register and an index register.

>Put all the stuff which needs to be cover by a base register after all
>the instructions, and start the area with a label, and "use" that.

That's one way to do it. Another is to consolidate all the constants at the 
beginning of the program using LOCTR. For example, like this:

PROGNAME J START
DATA LOCTR
(any eyecatcher data that you want at the beginning of your program)
CODE LOCTR
STARTSTM   14,12,12(13) or whatever method you use to save the registers
 LARL  12,PROGNAME establish base register for the program
 USING PROGNAME,12   Register 12 is just an example
(more code)
DATA LOCTR
(constants for the main routine)
CODE LOCTR
(code for the first subroutine)
DATA LOCTR
(constants for the first subroutine)
CODE LOCTR
(code for the second subroutine)
DATA LOCTR
(constants for the second subroutine)
...
 LTORG

"DATA" and "CODE" are arbitrary labels that are used to name the 
location counters that you need for your program. The assembler 
will consolidate all of the sections that use the same named location 
counter together, and will put them together in the order that each 
named location counter is first used. Because "DATA" is the first one 
used in the program, all DATA will be before all CODE.

There is also an unnamed location counter that is used for the first 
instruction (J  START).

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Greg Price

On 2018-11-16 1:47 AM, Ward Able, Grant wrote:

Can someone point me to a reasonably simple example?


If you can do branch instructions then you can do branch-relative 
instructions. Apart from RR instructions (BR, BASR, BALR, BASSM, BSM, 
BAKR and any others I've missed) replace the B that starts the branch 
instruction mnemonic with BR, or as I prefer to do, with J (for jump).


eg. BNH -> JNH and BCT -> JCT and BAS -> JAS etc.

Put all the stuff which needs to be cover by a base register after all 
the instructions, and start the area with a label, and "use" that.


eg.
LARL R11,Static
USING Static,R11
...

Static DC 0D  My module's constants and literals and non-RENT variables


Then all you need to cover is code generated by macros, which is why 
Peter mentioned ARCHLVL (look up the SYSSTATE macro) to cover macros 
with logic to test it, and the IEABRCX macro to cover the rest.


IEABRCX DEFINE
will define and activate the facility where the older "branch" 
instructions will be converted to newer "branch relative" instructions 
when encountered by the assembler in the source code.  With IEABRCX you 
could even leave the old branch source code as-is, but personally I 
prefer to use the newer mnemonics to make it obvious that the code is 
probably not covered by a base register, and to keep the listing a bit 
tidier.


IEABRCX is "better" than IEABRC because you can turn it on and off as 
needed. The most well known scenario where you might was to turn it off 
(I'd say) is if you have a branch table where you use the index register 
of the branch-on-condition instruction to provide an index into a table 
of branch (or even jump) instructions.


That's probably enough to get you started.  Have fun with it.

Cheers,
Greg P.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Ward Able, Grant
I have been following the ASMA034E discussion and am interested in learning how 
to do the new-fangled relative branching stuff.
Can someone point me to a reasonably simple example? I learned my Assembler in 
the 80's and have been using that way of coding ever since. I think it is time 
to upgrade my so-called skills.

Regards - Grant


DTCC Internal (Green)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: 15 November 2018 12:45
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASMA034E

ATTENTION! This email originated outside of DTCC; exercise caution.


A more modern (over 20 years old by now?) would suggest not having a USING for 
your "code" at all, but rather using relative branch with one register set up 
to point to your static data and a USING for that. It is relatively infrequent 
that your static data would exceed 4K, and even if it did you could often use 
long-displacement instructions to access any data that is more than 4K from the 
beginning. In some cases you might be able to take advantage of the "immediate" 
instructions and not even need access to static data.

The IEABRCX macro can help in modules that want to use relative branch, 
particularly if they invoke system macros.
Also be sure to identify the architecture level that macros are allowed to 
assume you are running with, via SYSSTATE ARCHLVL=.

Some macro expansions might need local code register addressability, but that 
is usually easy to provide.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DTCC DISCLAIMER: This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error, please notify us 
immediately and delete the email and any attachments from your system. The 
recipient should check this email and any attachments for the presence of 
viruses.  The company accepts no liability for any damage caused by any virus 
transmitted by this email.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Charles Mills
The other key tool for eliminating excessive base register dependencies is
LOCTR. Too long a topic for an e-mail, but LOCTR lets you code instructions
in whatever order you prefer, such as putting DC's at the "bottom," and lets
you use LTORG in the normal fashion -- while still putting everything that
might require base register addressability (such as DC's and literals and
possibly executed instructions) well within the first 4K of the CSECT. Look
it up in the assembler manual and/or search for a SHARE presentation.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, November 15, 2018 4:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASMA034E

A more modern (over 20 years old by now?) would suggest not having a USING 
for your "code" at all, but rather using relative branch with one register 
set up to point to your static data and a USING for that. It is relatively 
infrequent that your static data would exceed 4K, and even if it did you 
could often use long-displacement instructions to access any data that is 
more than 4K from the beginning. In some cases you might be able to take 
advantage of the "immediate" instructions and not even need access to 
static data.

The IEABRCX macro can help in modules that want to use relative branch, 
particularly if they invoke system macros.
Also be sure to identify the architecture level that macros are allowed to 
assume you are running with, via SYSSTATE ARCHLVL=.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Pew, Curtis G
On Nov 15, 2018, at 6:44 AM, Peter Relson  wrote:
> 
> A more modern (over 20 years old by now?) would suggest not having a USING 
> for your "code" at all, but rather using relative branch with one register 
> set up to point to your static data and a USING for that. It is relatively 
> infrequent that your static data would exceed 4K, and even if it did you 
> could often use long-displacement instructions to access any data that is 
> more than 4K from the beginning. In some cases you might be able to take 
> advantage of the "immediate" instructions and not even need access to 
> static data.
> 
> The IEABRCX macro can help in modules that want to use relative branch, 
> particularly if they invoke system macros.
> Also be sure to identify the architecture level that macros are allowed to 
> assume you are running with, via SYSSTATE ARCHLVL=.
> 
> Some macro expansions might need local code register addressability, but 
> that is usually easy to provide.
> 

+1

As I’ve had occasion to maintain assembler routines, I’ve tried to do this. It 
makes the code cleaner and I believe (I haven’t tested) it makes it run faster.


-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-15 Thread Peter Relson
A more modern (over 20 years old by now?) would suggest not having a USING 
for your "code" at all, but rather using relative branch with one register 
set up to point to your static data and a USING for that. It is relatively 
infrequent that your static data would exceed 4K, and even if it did you 
could often use long-displacement instructions to access any data that is 
more than 4K from the beginning. In some cases you might be able to take 
advantage of the "immediate" instructions and not even need access to 
static data.

The IEABRCX macro can help in modules that want to use relative branch, 
particularly if they invoke system macros.
Also be sure to identify the architecture level that macros are allowed to 
assume you are running with, via SYSSTATE ARCHLVL=.

Some macro expansions might need local code register addressability, but 
that is usually easy to provide.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-14 Thread Steely.Mark
Thank You - those worked.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cieri, Anthony
Sent: Wednesday, November 14, 2018 4:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASMA034E

There is a sample z/OS FTP client user exit in TCPIP.SEZAINST(EZAFCEXT).

In this sample exit, there are two "in-stream" macros called ABCINIT 
and ABCTERM. The ABCINIT macro supports setting multiple base registers.

Hth
Tony


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steely.Mark
Sent: Wednesday, November 14, 2018 4:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ASMA034E

The assembler program I am working on is receiving several  of these messages:

ASMA034E Operand =X' beyond active USING range by 148 bytes


I have tried all the examples to add a second register to the USING statement.
When the program executes it gets a S0C1.

Currently I have a macro call ENTER which sets up all the register and 
generates a USING statement with 1 register.

Does anyone have a macro or  a piece of code which will setup a USING statement 
with 2 registers.

Thank You

*** Disclaimer ***
This communication (including all attachments) is solely for the use of the 
person to whom it is addressed and is a confidential AAA communication. If you 
are not the intended recipient, any use, distribution, printing, or copying is 
prohibited. If you received this email in error, please immediately delete it 
and notify the sender.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
*** Disclaimer ***
This communication (including all attachments) is solely for the use of the 
person to whom it is addressed and is a confidential AAA communication. If you 
are not the intended recipient, any use, distribution, printing, or copying is 
prohibited. If you received this email in error, please immediately delete it 
and notify the sender.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-14 Thread Cieri, Anthony
There is a sample z/OS FTP client user exit in TCPIP.SEZAINST(EZAFCEXT).

In this sample exit, there are two "in-stream" macros called ABCINIT 
and ABCTERM. The ABCINIT macro supports setting multiple base registers. 

Hth
Tony


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steely.Mark
Sent: Wednesday, November 14, 2018 4:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ASMA034E

The assembler program I am working on is receiving several  of these messages:

ASMA034E Operand =X' beyond active USING range by 148 bytes


I have tried all the examples to add a second register to the USING statement.
When the program executes it gets a S0C1.

Currently I have a macro call ENTER which sets up all the register and 
generates a USING statement with 1 register.

Does anyone have a macro or  a piece of code which will setup a USING statement 
with 2 registers.

Thank You

*** Disclaimer ***
This communication (including all attachments) is solely for the use of the 
person to whom it is addressed and is a confidential AAA communication. If you 
are not the intended recipient, any use, distribution, printing, or copying is 
prohibited. If you received this email in error, please immediately delete it 
and notify the sender.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-14 Thread Binyamin Dissen
I believe it would be more educational for you to show what you tried.

On Wed, 14 Nov 2018 21:50:16 + "Steely.Mark" 
wrote:

:>The assembler program I am working on is receiving several  of these messages:
:>
:>ASMA034E Operand =X' beyond active USING range by 148 bytes
:>
:>
:>I have tried all the examples to add a second register to the USING statement.
:>When the program executes it gets a S0C1.
:>
:>Currently I have a macro call ENTER which sets up all the register and 
generates a USING statement with 1 register.
:>
:>Does anyone have a macro or  a piece of code which will setup a USING 
statement with 2 registers.

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ASMA034E

2018-11-14 Thread Farley, Peter x23353
In addition to adding a second register to the USING you also have to load the 
second register with (1st base register + 4096).  Just specifying it on the 
USING is not enough.

Your ENTER macro should support setting more than one base register for you 
(most of the ones I have seen will do so for you, at any rate).  Check the 
parameters to that macro and whatever documentation on it you may have to see 
how to do that.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steely.Mark
Sent: Wednesday, November 14, 2018 4:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ASMA034E

EXTERNAL EMAIL

The assembler program I am working on is receiving several  of these messages:

ASMA034E Operand =X' beyond active USING range by 148 bytes


I have tried all the examples to add a second register to the USING statement.
When the program executes it gets a S0C1.

Currently I have a macro call ENTER which sets up all the register and 
generates a USING statement with 1 register.

Does anyone have a macro or  a piece of code which will setup a USING statement 
with 2 registers.

Thank You
--


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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


ASMA034E

2018-11-14 Thread Steely.Mark
The assembler program I am working on is receiving several  of these messages:

ASMA034E Operand =X' beyond active USING range by 148 bytes


I have tried all the examples to add a second register to the USING statement.
When the program executes it gets a S0C1.

Currently I have a macro call ENTER which sets up all the register and 
generates a USING statement with 1 register.

Does anyone have a macro or  a piece of code which will setup a USING statement 
with 2 registers.

Thank You

*** Disclaimer ***
This communication (including all attachments) is solely for the use of the 
person to whom it is addressed and is a confidential AAA communication. If you 
are not the intended recipient, any use, distribution, printing, or copying is 
prohibited. If you received this email in error, please immediately delete it 
and notify the sender.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN