On 17 March 2017 at 14:22, Farley, Peter x23353
wrote:
> Thanks John, that does look like it would work, though it does still require
> adding that last "MACINIT LOCCTR" statement manually at the end of the
> program code and data.
>
> But if I have to manually
Hi Paul,
A pity our Emails crossed, with regards to the 2X'FF issue please read my
latest post
As for the Scon...I agree with you, you must submit a bug report for that
one
Regards,
Melvyn.
- Original Message -
From: "Paul Gilmartin"
Hi Martin and Tom, and all others who have contributed
My thanks to Martin for his support
To Tom...this thread originated when I tried to code LLIHF R5,4C'I' and then
later CIH R5,4C'I'
When it failed to assemble in z390 I turned to DeZhi and it failed there too
Is that code good, bad or ugly
On 2017-03-17, at 04:44, Martin Ward wrote:
>
> Given that 2X'FF' generates the same two bytes as X'',
> there is no reason why we should not be allowed to replace
> the latter by the former.
>
I tend more to be value-oriented. The operand of MVHHI is an
expression, and it is prudently
If you wanted to load two equated flag values, FOO and BAR, into the two bytes
of the immediate operand of an LHI, how would you code it?
LHI 0,(FOO*256)+BAR?
The assertion here is that LHI 0,AL1(FOO,BAR) would be more readable.
Charles
-Original Message-
From: IBM
Peter,
If the END assembler directive is one that can be redefined, you could write
your own END macro that inserts any required data areas and generates an _END
(or whatever it is that END was redefined as).
Keven
> On Mar 17, 2017, at 12:29, Farley, Peter x23353
On Fri, 17 Mar 2017 10:44:41 +, Martin Ward wrote:
>Given that 2X'FF' generates the same two bytes as X'',
>there is no reason why we should not be allowed to replace
>the latter by the former [in an immediate expression].
Maybe so, but I don't see it as a significant limitation.
LOCTR worked just the way you described, and does just what I need to do.
Thanks again!
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of John McKown
Sent: Friday, March 17, 2017 2:43 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
On Fri, Mar 17, 2017 at 1:31 PM, John McKown
wrote:
> On Fri, Mar 17, 2017 at 1:22 PM, Farley, Peter x23353 <
> peter.far...@broadridge.com> wrote:
>
>> Thanks John, that does look like it would work, though it does still
>> require adding that last "MACINIT LOCCTR"
Thanks John. I will give that a try.
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of John McKown
Sent: Friday, March 17, 2017 2:31 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: How to automatically position
On 2017-03-17, at 12:22, Farley, Peter x23353 wrote:
> Thanks John, that does look like it would work, though it does still require
> adding that last "MACINIT LOCCTR" statement manually at the end of the
> program code and data.
>
> But if I have to manually place a statement at the end of
On Fri, Mar 17, 2017 at 1:22 PM, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:
> Thanks John, that does look like it would work, though it does still
> require adding that last "MACINIT LOCCTR" statement manually at the end of
> the program code and data.
>
> But if I have to
I am heads down on a customer problem so cannot write a tutorial but I think
LOCTR might well be able to do what you want.
LOCTR will let you break the CSECT into pieces that are not necessarily in
the CSECT in the physical order of the instructions in the source. Let you
code stuff "now" that
Thanks John, that does look like it would work, though it does still require
adding that last "MACINIT LOCCTR" statement manually at the end of the program
code and data.
But if I have to manually place a statement at the end of the program anyway it
may as well be a MACDATA macro that just
On Fri, Mar 17, 2017 at 12:29 PM, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:
> I cannot see a way to do the following, so any enlightenment you can
> provide is appreciated.
>
> I have created new versions of an existing set of macros and the new
> versions require a fairly large
A little Rexx program would automate it alright :)
I am dealing with manipulating (converting) old code for living for sone time
now, in many languages and platforms. A little Rexx, Perl, Vbscript or
whatever always workZA
Sent from Yahoo Mail on Android
On Fri, Mar 17, 2017 at 1:51 PM,
That’s the only way I have been able to see to do it so far, what I am hoping
for is that there is a better (automated) way.
Peter
From: Ze'ev Atlas
Sent: Friday, March 17, 2017 1:43 PM
To: IBM Mainframe Assembler List; Farley, Peter x23353;
ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: How to
How about the good ol' way of separating into two version of the macro, for
code vs. Data and put the data in the endZA
Sent from Yahoo Mail on Android
On Fri, Mar 17, 2017 at 1:29 PM, Farley, Peter
x23353 wrote: I cannot see a way to do the
following, so
I cannot see a way to do the following, so any enlightenment you can provide is
appreciated.
I have created new versions of an existing set of macros and the new versions
require a fairly large set of non-reentrant data areas defined in the CSECT in
which they are used. The first macro
I agree; in general, I don't see why immediate instructions shouldn't have
the same power as the non-immediates. i.e. anything one can define with DC.
However, I foresee that making a business case that out-weighs the cost and
effort will be a problem.
sas
On Fri, Mar 17, 2017 at 8:17 AM,
Without having taken the time to parse every detail below I think I agree with
@Martin.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Martin Ward
Sent: Friday, March 17, 2017 3:45 AM
To:
Melvyn Maltz has proposed that repeat counts should be allowed
in immediate operands. Given that the modern instructions allow
larger immediate operands (up to 32 bits), this seems to me to be
a very sensible proposal.
A DC and an immediate operand both generate data in the current location.
22 matches
Mail list logo