Re: How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread Tony Harminc
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

Re: HLASM "Anomaly"

2017-03-17 Thread MELVYN MALTZ
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"

Re: HLASM Anomaly

2017-03-17 Thread MELVYN MALTZ
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

Re: HLASM "Anomaly"

2017-03-17 Thread Paul Gilmartin
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

Re: HLASM "Anomaly"

2017-03-17 Thread Charles Mills
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

Re: How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread Keven Hall
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

Re: HLASM "Anomaly"

2017-03-17 Thread Tom Marchant
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.

Re: How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread Farley, Peter x23353
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

Re: How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread John McKown
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"

Re: How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread Farley, Peter x23353
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

Re: How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread Paul Gilmartin
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

Re: How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread John McKown
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

Re: How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread Charles Mills
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

Re: How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread Farley, Peter x23353
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

Re: How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread John McKown
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

Re: How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread Ze'ev Atlas
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,

Re: How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread Farley, Peter x23353
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

Re: How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread Ze'ev Atlas
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

How to automatically position generated data areas after all program-defined areas

2017-03-17 Thread Farley, Peter x23353
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

Re: HLASM "Anomaly"

2017-03-17 Thread Steve Smith
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,

Re: HLASM "Anomaly"

2017-03-17 Thread Charles Mills
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:

Re: HLASM "Anomaly"

2017-03-17 Thread Martin Ward
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.