Re: Base registers

[Martin Truebner]

John,

>> I think VSE doesn't support GOFF.

That is true- the requirement has been raised long ago- but it is still
open.

>> ... whether it has added support for relative-immediate external references,
but it should be easy to test.

I did. Here is what I get (in line with above):

** ASMA215W Relative Immediate external relocation in NOGOFF object text

To be honest: this support would be a nice there (not even "to have")
item. What is required is (with GOFF support) long names.

What is even more required is a working ADEXIT (!).
--
Martin

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

Re: Checking for "more restrictive" TYPECHECK(REGISTER) at assemble time

[Ray Mullins]

On 2012-06-19 10:44, John Ehrman wrote:

The SYSATTRA internal function can retrieve the Assembler Type assigned by
an EQU,and the value is independent of the EQUated symbol (so you don't
have to parse special names).  Might that be useful?

John Ehrman


That's actually what I'm doing now.  :)

I was hoping to create logic that didn't require setting of the 5th EQU
parameter. Maybe I'll add check logic and insure that any register EQU used
as a parameter has the 5th parameter coded, and if not, fire off a nasty MNOTE.


--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/

German is essentially a form of assembly language consisting entirely of far 
calls heavily accented with throaty guttural sounds. ---ilvi
French is essentially German with messed-up pronunciation and spelling.  
--Robert B Wilson
English is essentially French converted to 7-bit ASCII.  ---Christophe Pierret 
[for Alain LaBonté]

Re: Base registers

[John Ehrman]

Martin Truebner asked
>> ...both old OBJ...object formats since 2004.

>Would that include z/VSE (any)

I think VSE doesn't support GOFF.  I don't whether it has added support for
relative-immediate external references, but it should be easy to test.

John Ehrman

Re: Checking for "more restrictive" TYPECHECK(REGISTER) at assemble time

[John Ehrman]

The SYSATTRA internal function can retrieve the Assembler Type assigned by
an EQU,and the value is independent of the EQUated symbol (so you don't
have to parse special names).  Might that be useful?

John Ehrman

Re: Checking for "more restrictive" TYPECHECK(REGISTER) at assemble time

[Duffy Nightingale]

1st time I heard that I laughed so hard I kicked the slats out of my
cradle!! Duf

On Tue, Jun 19, 2012 at 11:51 AM, McKown, John <
john.mck...@healthmarkets.com> wrote:

> Ah! I see, said the blind man. As he picked up his hammer and saw.
>
> --
> John McKown
> Systems Engineer IV
> IT
>
> Administrative Services Group
>
> HealthMarkets®
>
> 9151 Boulevard 26 . N. Richland Hills . TX 76010
> (817) 255-3225 phone .
> john.mck...@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® is the brand name for products underwritten and
> issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake
> Life Insurance Company®, Mid-West National Life Insurance Company of
> TennesseeSM and The MEGA Life and Health Insurance Company.SM
>
> > -Original Message-
> > From: Ray Mullins [mailto:m...@lerctr.org]
> > Sent: Tuesday, June 19, 2012 1:32 PM
> > To: IBM Mainframe Assembler List
> > Cc: McKown, John
> > Subject: Re: Checking for "more restrictive"
> > TYPECHECK(REGISTER) at assemble time
> >
> > LLH comes in at MACHINE(ZS-3), so the macro substitutes for
> > LLH if assembled
> > with MACHINE(ZS-2) and earlier. (O' is a nice addition.)
> >
> > I'm using a combination of LH and IILH (not IILL, as I wrote)
> > to properly
> > reflect the operation of LLH. LH wants GR32, IILH wants GR64.
> > I'm working
> > around that if the first operand is one of our register
> > equates, but if
> > someone slips something like LLH MYREG,ASCBASID where MYREG
> > is tagged as GR,
> > or not tagged at all, and "more restrictive" is not in
> > effect, I'd like to
> > bypass the code that gets the proper GR32 and GR64 EQUs.
> >
> > If "more restrictive" is in effect and they're using GR for their own
> > equate, then screw 'em, let them deal with the ASMA323Ws. :)
> >
> > It's not a life-or-death situation. Let me just say that in
> > what we've
> > currently got now in our macro set, it would be nice to know
> > when HLASM is
> > in "more restrictive" mode.
> >
> > On 2012-06-19 09:57, McKown, John wrote:
> > > I'm not entirely sure exactly what you want. But one thing
> > that I do is use the Assembler parm MACHINE(architecture) to
> > indicate my "highest level" instruction set. E.g. I use
> > "//ASM EXEC PGM=ASMA90,PARM='MACHINE(ZSERIES-3)' to cause an
> > assembler error if I were to use EXRL other instruction which
> > would abend with an S0C1 on my z9BC.
> > >
> > >
> > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asm
> > i1020/A.2.30
> > >
> > > Or is it that you want some macros to use which would
> > expand to an LLH, if at the proper minimal MACHINE level, or
> > to a "equivalent" set of "lower MACHINE level" instructions?
> > If you want to test this, look at&SYSOPT_OPTABLE at:
> > >
> > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asm
> > r1020/7.10.28
> > >
> > > I don't understand the comments about LLH. Is is LLH vs.
> > LLGH? And you want, somehow, to determine which to use? LLH
> > should use GR32 equates and LLGH should use GR64 equates.
> > >
> > > --
> > > John McKown
> > > Systems Engineer IV
> > > IT
> > >
> > > Administrative Services Group
> > >
> > > HealthMarkets®
> > >
> > > 9151 Boulevard 26 . N. Richland Hills . TX 76010
> > > (817) 255-3225 phone .
> > > john.mck...@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® is the brand name for products underwritten
> > and issued by the insurance subsidiaries of HealthMarkets,
> > Inc. -The Chesapeake Life Insurance Company®, 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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ray Mullins
> > >> Sent: Tuesday, June 19, 2012 11:29 AM
> > >> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> > >> Subject: Checking for "more restrictive" TYPECHECK(REGISTER)
> > >> at assemble time
> > >>
> > >> Hi everyone,
> > >>
> > >> I've been through the Fine Manual and the list archives, and
> > >> according to my
> > >> perusal this is not possible, but I'll throw it out there to
> > >> the brain trust
> > >> that is ASSEMBLER-LIST.
> > >>
> > >> I'm working on some instruction substitution macros to catch
> > >> any slips of
> > >> instructions like LLH into code that for one reason or
> > >> another has to be
> > >> assembled with MACHINE(ZS-2), as well as better MACHINEs. I

Re: Checking for "more restrictive" TYPECHECK(REGISTER) at assemble time

[McKown, John]

Ah! I see, said the blind man. As he picked up his hammer and saw.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 . N. Richland Hills . TX 76010
(817) 255-3225 phone .
john.mck...@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® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM

> -Original Message-
> From: Ray Mullins [mailto:m...@lerctr.org]
> Sent: Tuesday, June 19, 2012 1:32 PM
> To: IBM Mainframe Assembler List
> Cc: McKown, John
> Subject: Re: Checking for "more restrictive"
> TYPECHECK(REGISTER) at assemble time
>
> LLH comes in at MACHINE(ZS-3), so the macro substitutes for
> LLH if assembled
> with MACHINE(ZS-2) and earlier. (O' is a nice addition.)
>
> I'm using a combination of LH and IILH (not IILL, as I wrote)
> to properly
> reflect the operation of LLH. LH wants GR32, IILH wants GR64.
> I'm working
> around that if the first operand is one of our register
> equates, but if
> someone slips something like LLH MYREG,ASCBASID where MYREG
> is tagged as GR,
> or not tagged at all, and "more restrictive" is not in
> effect, I'd like to
> bypass the code that gets the proper GR32 and GR64 EQUs.
>
> If "more restrictive" is in effect and they're using GR for their own
> equate, then screw 'em, let them deal with the ASMA323Ws. :)
>
> It's not a life-or-death situation. Let me just say that in
> what we've
> currently got now in our macro set, it would be nice to know
> when HLASM is
> in "more restrictive" mode.
>
> On 2012-06-19 09:57, McKown, John wrote:
> > I'm not entirely sure exactly what you want. But one thing
> that I do is use the Assembler parm MACHINE(architecture) to
> indicate my "highest level" instruction set. E.g. I use
> "//ASM EXEC PGM=ASMA90,PARM='MACHINE(ZSERIES-3)' to cause an
> assembler error if I were to use EXRL other instruction which
> would abend with an S0C1 on my z9BC.
> >
> >
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asm
> i1020/A.2.30
> >
> > Or is it that you want some macros to use which would
> expand to an LLH, if at the proper minimal MACHINE level, or
> to a "equivalent" set of "lower MACHINE level" instructions?
> If you want to test this, look at&SYSOPT_OPTABLE at:
> >
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asm
> r1020/7.10.28
> >
> > I don't understand the comments about LLH. Is is LLH vs.
> LLGH? And you want, somehow, to determine which to use? LLH
> should use GR32 equates and LLGH should use GR64 equates.
> >
> > --
> > John McKown
> > Systems Engineer IV
> > IT
> >
> > Administrative Services Group
> >
> > HealthMarkets®
> >
> > 9151 Boulevard 26 . N. Richland Hills . TX 76010
> > (817) 255-3225 phone .
> > john.mck...@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® is the brand name for products underwritten
> and issued by the insurance subsidiaries of HealthMarkets,
> Inc. -The Chesapeake Life Insurance Company®, 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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ray Mullins
> >> Sent: Tuesday, June 19, 2012 11:29 AM
> >> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> >> Subject: Checking for "more restrictive" TYPECHECK(REGISTER)
> >> at assemble time
> >>
> >> Hi everyone,
> >>
> >> I've been through the Fine Manual and the list archives, and
> >> according to my
> >> perusal this is not possible, but I'll throw it out there to
> >> the brain trust
> >> that is ASSEMBLER-LIST.
> >>
> >> I'm working on some instruction substitution macros to catch
> >> any slips of
> >> instructions like LLH into code that for one reason or
> >> another has to be
> >> assembled with MACHINE(ZS-2), as well as better MACHINEs. In
> >> one program, we
> >> are experimenting with TYPECHECK(REGISTER) by coding two sets
> >> of equates,
> >> one GR32 and one GR64. Our one hitch is that one of these macros -
> >> specifically one for LLH, uses one instruction that wants
> GR32 and one
> >> instruction that wants GR64. (I can see why instructions like
> >> IILL want GR64
> >> - I may not agree with it, but I can see the premise.)
> >>
> >> Our basic register equates are defined such that I can
> >> deter

Re: Base registers

[Martin Truebner]

John,

>> ...both old OBJ...object formats since 2004.

Would that include z/VSE (any)

--
Martin

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

Re: Checking for "more restrictive" TYPECHECK(REGISTER) at assemble time

[Ray Mullins]

LLH comes in at MACHINE(ZS-3), so the macro substitutes for LLH if assembled
with MACHINE(ZS-2) and earlier. (O' is a nice addition.)

I'm using a combination of LH and IILH (not IILL, as I wrote) to properly
reflect the operation of LLH. LH wants GR32, IILH wants GR64. I'm working
around that if the first operand is one of our register equates, but if
someone slips something like LLH MYREG,ASCBASID where MYREG is tagged as GR,
or not tagged at all, and "more restrictive" is not in effect, I'd like to
bypass the code that gets the proper GR32 and GR64 EQUs.

If "more restrictive" is in effect and they're using GR for their own
equate, then screw 'em, let them deal with the ASMA323Ws. :)

It's not a life-or-death situation. Let me just say that in what we've
currently got now in our macro set, it would be nice to know when HLASM is
in "more restrictive" mode.

On 2012-06-19 09:57, McKown, John wrote:

I'm not entirely sure exactly what you want. But one thing that I do is use the Assembler parm 
MACHINE(architecture) to indicate my "highest level" instruction set. E.g. I use 
"//ASM EXEC PGM=ASMA90,PARM='MACHINE(ZSERIES-3)' to cause an assembler error if I were to 
use EXRL other instruction which would abend with an S0C1 on my z9BC.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asmi1020/A.2.30

Or is it that you want some macros to use which would expand to an LLH, if at the proper minimal 
MACHINE level, or to a "equivalent" set of "lower MACHINE level" instructions? If 
you want to test this, look at&SYSOPT_OPTABLE at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asmr1020/7.10.28

I don't understand the comments about LLH. Is is LLH vs. LLGH? And you want, 
somehow, to determine which to use? LLH should use GR32 equates and LLGH should 
use GR64 equates.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 . N. Richland Hills . TX 76010
(817) 255-3225 phone .
john.mck...@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® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, 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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ray Mullins
Sent: Tuesday, June 19, 2012 11:29 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Checking for "more restrictive" TYPECHECK(REGISTER)
at assemble time

Hi everyone,

I've been through the Fine Manual and the list archives, and
according to my
perusal this is not possible, but I'll throw it out there to
the brain trust
that is ASSEMBLER-LIST.

I'm working on some instruction substitution macros to catch
any slips of
instructions like LLH into code that for one reason or
another has to be
assembled with MACHINE(ZS-2), as well as better MACHINEs. In
one program, we
are experimenting with TYPECHECK(REGISTER) by coding two sets
of equates,
one GR32 and one GR64. Our one hitch is that one of these macros -
specifically one for LLH, uses one instruction that wants GR32 and one
instruction that wants GR64. (I can see why instructions like
IILL want GR64
- I may not agree with it, but I can see the premise.)

Our basic register equates are defined such that I can
determine the GR32
and GR64 equates from the register supplied. However, it
would helpful to
know if HLASM has gone into its "more restrictive" type
checking (their
words from Appendix N from the Programmer's Guide) to add this extra
processing, or, if not, don't bother. There's no nice
&SYSOPT_ flag for
TYPECHECK, nor one saying "more restrictive" has kicked in.
I realize that
this may be difficult, nigh impossible, depending on where in
the assembly
process that "more restrictive" kicks in.

To handle any register equates that don't conform to our
naming standard
(something like CBBASE EQU R10), the oft-requested ability to
SETA to an EQU
value inside a macro would be wonderful. But I'm not holding
my breath on
that one.

Short of putting in a formal enhancement request for a
&SYSOPT_ or other
flag (or one for TYPECHECK and one for "more restrictive"
checking), or
waving at Sharuff and asking if he thinks this is a good
idea, does anyone
have any ideas?

Cheers,
Ray

--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/

German is essentially a form of assembly language consisting
entirely of far calls heavily accented with throaty guttural
sounds. ---ilvi
French is essentially German with messed-up pronunciation and
spelling.  --Robert B Wilson
English is essentially French converted to 7-bit ASCII.
---Christophe Pierret [for

Re: Base registers

[McKown, John]

> -Original Message-
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John Ehrman
> Sent: Tuesday, June 19, 2012 11:55 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Base registers
>
> >> ... I prefer using Branch Relative, Relative (such as LARL
> vice LAY),
> and Immediate (such as LHI vice LH) instructions. And I do
> recognize that
> it is not always >possible, such as accessing locations outside of the
> enclosing CSECT.
> >>
> >That would require an enhancement to Binder.  But that's not
> >unthinkable.  But it would introduce a class of addressability
> >errors that could be detected only at link time, not at assembly.
> >Probably not justified by ROI.
>
> Relative-immediate references to external symbols has been
> available for
> both old OBJ and new GOFF object formats since 2004.
>
> John Ehrman

I'm not up on the enhancements which can be exploited when GOFF is used. I've 
only started using GOFF since I've learned how to write LE DLLs in HLASM. And 
I'm just weird enough to have actually done and so that I could use the DLL in 
a z/UNIX command, written in LE enabled HLASM. All of which I could gladly 
abandon if I could get a C license. Ain't gonna happen no time soon 'round 
heayr.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@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

Re: Checking for "more restrictive" TYPECHECK(REGISTER) at assemble time

[McKown, John]

I'm not entirely sure exactly what you want. But one thing that I do is use the 
Assembler parm MACHINE(architecture) to indicate my "highest level" instruction 
set. E.g. I use "//ASM EXEC PGM=ASMA90,PARM='MACHINE(ZSERIES-3)' to cause an 
assembler error if I were to use EXRL other instruction which would abend with 
an S0C1 on my z9BC.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asmi1020/A.2.30

Or is it that you want some macros to use which would expand to an LLH, if at 
the proper minimal MACHINE level, or to a "equivalent" set of "lower MACHINE 
level" instructions? If you want to test this, look at &SYSOPT_OPTABLE at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asmr1020/7.10.28

I don't understand the comments about LLH. Is is LLH vs. LLGH? And you want, 
somehow, to determine which to use? LLH should use GR32 equates and LLGH should 
use GR64 equates.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 . N. Richland Hills . TX 76010
(817) 255-3225 phone .
john.mck...@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® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, 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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ray Mullins
> Sent: Tuesday, June 19, 2012 11:29 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Checking for "more restrictive" TYPECHECK(REGISTER)
> at assemble time
>
> Hi everyone,
>
> I've been through the Fine Manual and the list archives, and
> according to my
> perusal this is not possible, but I'll throw it out there to
> the brain trust
> that is ASSEMBLER-LIST.
>
> I'm working on some instruction substitution macros to catch
> any slips of
> instructions like LLH into code that for one reason or
> another has to be
> assembled with MACHINE(ZS-2), as well as better MACHINEs. In
> one program, we
> are experimenting with TYPECHECK(REGISTER) by coding two sets
> of equates,
> one GR32 and one GR64. Our one hitch is that one of these macros -
> specifically one for LLH, uses one instruction that wants GR32 and one
> instruction that wants GR64. (I can see why instructions like
> IILL want GR64
> - I may not agree with it, but I can see the premise.)
>
> Our basic register equates are defined such that I can
> determine the GR32
> and GR64 equates from the register supplied. However, it
> would helpful to
> know if HLASM has gone into its "more restrictive" type
> checking (their
> words from Appendix N from the Programmer's Guide) to add this extra
> processing, or, if not, don't bother. There's no nice
> &SYSOPT_ flag for
> TYPECHECK, nor one saying "more restrictive" has kicked in.
> I realize that
> this may be difficult, nigh impossible, depending on where in
> the assembly
> process that "more restrictive" kicks in.
>
> To handle any register equates that don't conform to our
> naming standard
> (something like CBBASE EQU R10), the oft-requested ability to
> SETA to an EQU
> value inside a macro would be wonderful. But I'm not holding
> my breath on
> that one.
>
> Short of putting in a formal enhancement request for a
> &SYSOPT_ or other
> flag (or one for TYPECHECK and one for "more restrictive"
> checking), or
> waving at Sharuff and asking if he thinks this is a good
> idea, does anyone
> have any ideas?
>
> Cheers,
> Ray
>
> --
> M. Ray Mullins
> Roseville, CA, USA
> http://www.catherdersoftware.com/
>
> German is essentially a form of assembly language consisting
> entirely of far calls heavily accented with throaty guttural
> sounds. ---ilvi
> French is essentially German with messed-up pronunciation and
> spelling.  --Robert B Wilson
> English is essentially French converted to 7-bit ASCII.
> ---Christophe Pierret [for Alain LaBonté]
>
>

Re: Base registers

[John Ehrman]

>> ... I prefer using Branch Relative, Relative (such as LARL vice LAY),
and Immediate (such as LHI vice LH) instructions. And I do recognize that
it is not always >possible, such as accessing locations outside of the
enclosing CSECT.
>>
>That would require an enhancement to Binder.  But that's not
>unthinkable.  But it would introduce a class of addressability
>errors that could be detected only at link time, not at assembly.
>Probably not justified by ROI.

Relative-immediate references to external symbols has been available for
both old OBJ and new GOFF object formats since 2004.

John Ehrman

Checking for "more restrictive" TYPECHECK(REGISTER) at assemble time

[Ray Mullins]

Hi everyone,

I've been through the Fine Manual and the list archives, and according to my
perusal this is not possible, but I'll throw it out there to the brain trust
that is ASSEMBLER-LIST.

I'm working on some instruction substitution macros to catch any slips of
instructions like LLH into code that for one reason or another has to be
assembled with MACHINE(ZS-2), as well as better MACHINEs. In one program, we
are experimenting with TYPECHECK(REGISTER) by coding two sets of equates,
one GR32 and one GR64. Our one hitch is that one of these macros -
specifically one for LLH, uses one instruction that wants GR32 and one
instruction that wants GR64. (I can see why instructions like IILL want GR64
- I may not agree with it, but I can see the premise.)

Our basic register equates are defined such that I can determine the GR32
and GR64 equates from the register supplied. However, it would helpful to
know if HLASM has gone into its "more restrictive" type checking (their
words from Appendix N from the Programmer's Guide) to add this extra
processing, or, if not, don't bother. There's no nice &SYSOPT_ flag for
TYPECHECK, nor one saying "more restrictive" has kicked in.  I realize that
this may be difficult, nigh impossible, depending on where in the assembly
process that "more restrictive" kicks in.

To handle any register equates that don't conform to our naming standard
(something like CBBASE EQU R10), the oft-requested ability to SETA to an EQU
value inside a macro would be wonderful. But I'm not holding my breath on
that one.

Short of putting in a formal enhancement request for a &SYSOPT_ or other
flag (or one for TYPECHECK and one for "more restrictive" checking), or
waving at Sharuff and asking if he thinks this is a good idea, does anyone
have any ideas?

Cheers,
Ray

--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/

German is essentially a form of assembly language consisting entirely of far 
calls heavily accented with throaty guttural sounds. ---ilvi
French is essentially German with messed-up pronunciation and spelling.  
--Robert B Wilson
English is essentially French converted to 7-bit ASCII.  ---Christophe Pierret 
[for Alain LaBonté]

Re: Base registers

[Gord Tomlin]

You can refer to entry points outside of the current CSECT if you
specify the GOFF assembler option.

--

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


On 2012-06-19 10:04, Paul Gilmartin wrote:

On Jun 19, 2012, at 07:51, McKown, John wrote:


... I prefer using Branch Relative, Relative (such as LARL vice LAY), and 
Immediate (such as LHI vice LH) instructions. And I do recognize that it is not 
always possible, such as accessing locations outside of the enclosing CSECT.


That would require an enhancement to Binder.  But that's not
unthinkable.  But it would introduce a class of addressability
errors that could be detected only at link time, not at assembly.
Probably not justified by ROI.

-- gil

Re: Base registers

[Tom Marchant]

On Tue, 19 Jun 2012 08:04:35 -0600, Paul Gilmartin wrote:

>On Jun 19, 2012, at 07:51, McKown, John wrote:
>>
>> ... I prefer using Branch Relative, Relative (such as
>>LARL vice LAY), and Immediate (such as LHI vice LH)
>>instructions. And I do recognize that it is not always
>>possible, such as accessing locations outside of the
>>enclosing CSECT.
>>
>That would require an enhancement to Binder.

Binder and HLASM.  I've not used it yet, but it is there.

--
Tom Marchant

Re: Base registers

[McKown, John]

JRI is nice and short. Again, almost anything simple is acceptable to me. I 
originally used "baseless" because that was what I saw in many messages. I'm 
now bowing out of the discussion and awaiting for a concensus to occur. I will 
just reiterate that, to the extent possible, I prefer using Branch Relative, 
Relative (such as LARL vice LAY), and Immediate (such as LHI vice LH) 
instructions. And I do recognize that it is not always possible, such as 
accessing locations outside of the enclosing CSECT.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John Gilmore
> Sent: Tuesday, June 19, 2012 8:45 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Base registers
>
> "Jumpify" is acceptable as a nonce word, in, say, EJ's title.
>
> It is nevertheless barbarous English and should not be adopted for
> routine use.
>
> "JRI"?
>
> --jg
>
> On 6/19/12, McKown, John  wrote:
> > OK, I can live with "jumpify". I would just like something that is
> > "generally acceptable" to the community. Only minus is that
> it doesn't say
> > anything about the use of Relative and Immediate
> instructions. Of which I am
> > also a big fan.
> >
> > --
> > John McKown
> > Systems Engineer IV
> > IT
> >
> > Administrative Services Group
> >
> > HealthMarkets(r)
> >
> > 9151 Boulevard 26 * N. Richland Hills * TX 76010
> > (817) 255-3225 phone *
> > john.mck...@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
> >
>
>

Re: Base registers

[Paul Gilmartin]

On Jun 19, 2012, at 07:51, McKown, John wrote:
>
> ... I prefer using Branch Relative, Relative (such as LARL vice LAY), and 
> Immediate (such as LHI vice LH) instructions. And I do recognize that it is 
> not always possible, such as accessing locations outside of the enclosing 
> CSECT.
>
That would require an enhancement to Binder.  But that's not
unthinkable.  But it would introduce a class of addressability
errors that could be detected only at link time, not at assembly.
Probably not justified by ROI.

-- gil

Re: Base registers

[John Gilmore]

"Jumpify" is acceptable as a nonce word, in, say, EJ's title.

It is nevertheless barbarous English and should not be adopted for
routine use.

"JRI"?

--jg

On 6/19/12, McKown, John  wrote:
> OK, I can live with "jumpify". I would just like something that is
> "generally acceptable" to the community. Only minus is that it doesn't say
> anything about the use of Relative and Immediate instructions. Of which I am
> also a big fan.
>
> --
> John McKown
> Systems Engineer IV
> IT
>
> Administrative Services Group
>
> HealthMarkets(r)
>
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone *
> john.mck...@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
>

Re: Base registers

[Joe Testa]

To make it IBM-like, you'd have to call it the "Jumpify Facility". :-)

--
From: "Peter Relson" 
Sent: Tuesday, June 19, 2012 9:21 AM
To: 
Subject:  Re: Base registers


My quibble with the terms being bandied about is that neither "unbased"
nor "baseless" is factually correct for a large percentage of modules that
use relative branches. They have a "base" to their static data (and, yes,
sometimes that "base" is not persistent and is created only when needed).
They just do not tend to need a base for their code (aside from when they
use macros that have not been "jumpified").

If you think of the addressablity to code as being via "codereg" they have
been de-codereg'd (not a pleasing term, of course).

I think everyone these days understands what someone means when they use
the non-word "jumpify". Is more than that needed? Creating more
terminology just for the sake of doing so seems unwieldy (and perhaps it
could be said "IBM-like").

Peter Relson
z/OS Core Technology Design

Re: Base registers

[McKown, John]

OK, I can live with "jumpify". I would just like something that is "generally 
acceptable" to the community. Only minus is that it doesn't say anything about 
the use of Relative and Immediate instructions. Of which I am also a big fan.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@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

Re: Base registers

[Peter Relson]

My quibble with the terms being bandied about is that neither "unbased"
nor "baseless" is factually correct for a large percentage of modules that
use relative branches. They have a "base" to their static data (and, yes,
sometimes that "base" is not persistent and is created only when needed).
They just do not tend to need a base for their code (aside from when they
use macros that have not been "jumpified").

If you think of the addressablity to code as being via "codereg" they have
been de-codereg'd (not a pleasing term, of course).

I think everyone these days understands what someone means when they use
the non-word "jumpify". Is more than that needed? Creating more
terminology just for the sake of doing so seems unwieldy (and perhaps it
could be said "IBM-like").

Peter Relson
z/OS Core Technology Design

Re: ASSEMBLER-LIST Digest - 17 Jun 2012 to 18 Jun 2012 (#2012-113)

[Sharuff Morsa3]

This is a good idea - I've raised an RFE:

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=23635


If you also believe this is useful, please add comment/votes to the RFE
entry

Sharuff

Sharuff Morsa - IBM Hursley


>IBM Mainframe Assembler List  wrote on
19/06/2012 05:00:37:
> --
>
> Date:Mon, 18 Jun 2012 09:16:35 -0600
> From:Paul Gilmartin 
> Subject: YA wishlist item.
>
> Excerpted from IBM-MAIN:
>
> >The assembly uses the BATCH option. There are multiple assembly steps
and
> >the RETURN CODE you are quoting is from the LAST batched assemble.
> >
> The OP and several followups (including mine) were misled
> by this.  It would be a useful enhancement if HLASM provided
> a summary summary line:
>
> Number of assemblies: nnn  Highest return code: 12
>
> >If you search through the listing you'll find the non-zero return code.
> >
> Well, yah, I usually do that.
>
> -- gil
>
> --
>
> Date:Mon, 18 Jun 2012 10:30:31 -0500
> From:"McKown, John" 
> Subject: Re: Base registers
>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU