Immediate operands won't accept a duplication factor...why not ?
Can't find a reason in the HLASM manual
Try these...
CFI R1,4X'FF'
CFI R1,X''
CFI R1,-1
AHI R1,2X'FF'
AHI R1,X''
AHI R1,-1
Melvyn Maltz
To restate what I'm asking for...
Now that we have 2 and 4-byte immediate values it would make sense
to allow both duplication factor and explicit length for these
Currently the instructions below would fail
AHI 1,2X'FF'
CFI 1,XL4'FF'
Rather more contentious, I agree, is to
I really can't understand why we're making such an indigestible meal of
all this.
Take for example, AHI R1,2X'FF'. What does that even *mean*? If it
*means* AHI R1,-1, then write it like that, so that the unfortunate
programmer who has to maintain your code doesn't have to cast runes to
know what
I think I have a clearer picture now than I had previously: for instructions,
the operand parser evaluates expressions, while for DC/DS operands, the operand
parser evaluates duplication factors. For example:
LHI 0,2X'FF' is invalid because the operand is not an expression
LHI 0.2*X'FF' is val
That's just the way it is... i.e. there is no reason.
DC supports a whole bunch of stuff that immediate operands do not.
Sometimes, you just have to ORG *-2 (or 4), and DC it. Be careful with
f-word-aligned data!
e.g.:
CNOP 2,4
LLILF R15,*
ORG *-4
DC V(EXTRTN1)
BASSM R14,R15
AFAIK, you cou
Sent: Wednesday, February 22, 2017 4:04 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
That's just the way it is... i.e. there is no reason.
DC supports a whole bunch of stuff that immediate operands do not.
Sometimes, you just have to ORG *-2 (or 4), and DC it. Be careful
What does "immediate" mean to you?
In this case, it means immediately available within the
instruction itself.
Replication would then expand outside of the instruction and into
the instruction stream. That would then cause the next byte,
beyond the instruction, to be an OPCODE by instruction
From: "Steve Thompson"
Sent: Thursday, February 23, 2017 11:55 PM
What does "immediate" mean to you?
In this case, it means immediately available within the
instruction itself.
Replication would then expand outside of the instruction
Why? It is an Immediate instruction.
and into the ins
alf Of Steve Thompson
Sent: Thursday, February 23, 2017 4:56 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
What does "immediate" mean to you?
In this case, it means immediately available within the instruction itself.
Replication would then expand outside of the instruct
Ah, I see why you all are having a problem with this.
And me, being an old ALC programmer, this is intuitively obvious.
In fact, there are several changes to HLASM that I disagreed
with, because they then caused programs I had written earlier to
start getting informative messages, where they d
On
Behalf Of Steve Thompson
Sent: Thursday, February 23, 2017 4:56 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
What does "immediate" mean to you?
In this case, it means immediately available within the instruction itself.
Replication would then expand outside o
On 2017-02-23, at 07:57, Steve Thompson wrote:
> Ah, I see why you all are having a problem with this.
>
> And me, being an old ALC programmer, this is intuitively obvious. In fact,
> there are several changes to HLASM that I disagreed with, because they then
> caused programs I had written ear
On 02/23/2017 10:09 AM, Paul Gilmartin wrote:
On 2017-02-23, at 07:57, Steve Thompson wrote:
Ah, I see why you all are having a problem with this.
And me, being an old ALC programmer, this is intuitively obvious. In fact,
there are several changes to HLASM that I disagreed with, because they
On 2017-02-23, at 10:31, Steve Thompson wrote:
>>>
>> Informative? Or Warning? Do you then disagree with warnings on
>> multiple base-displacement resolutions?
>
> I sometimes run into this, and can't figure out why the assembler even issued
> the message. But when it happens I do verify that
On 02/23/2017 01:16 PM, Paul Gilmartin wrote:
On 2017-02-23, at 10:31, Steve Thompson wrote:
Informative? Or Warning? Do you then disagree with warnings on
multiple base-displacement resolutions?
I sometimes run into this, and can't figure out why the assembler even issued the
message. Bu
On 2017-02-23, at 11:16, Paul Gilmartin wrote:
>
> What are the limits on the operand of AHI? What of:
>
> AEQU -32768
> DC Y(A)
> AHI R1,AOK, I believe.
>
> BEQU 32767
> DC Y(B)
> AHI R1,BOK, I believe.
>
> cEQU 65535
>
Another reason not to allow DC-type operands in immediate operands: consider
AHI 0,(N)X'F'
The Assembler can't tell that the instruction is indeed 4 bytes long.
I suppose it could do some acrobatics, but the cost vs. value seems excessive.
John
RV.UGA.EDU] On
Behalf Of Paul Gilmartin
Sent: February-23-17 11:05 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
On 2017-02-23, at 11:16, Paul Gilmartin wrote:
>
> What are the limits on the operand of AHI? What of:
>
> AEQU -32768
> DC Y(A
On 2017-02-23, at 23:26, Webster, Chris wrote:
> HLASM correctly refers to POPs since it is not describing each instruction.
> POPs uses 'treated as' for describing different operands. The term 'treated
> as' is used frequently with different instructions and appears to accurately
> describe
Fellow listers
I used to develop and maintain HLASM and there were lots of internal
discussions about how to handle items like 16 bit immediate opearnds.
One point is that internally the assembler has an expression processor for
instruction operands, and it has another one for DC operands - why
On 2017-02-23, at 23:54, John Dravnieks wrote:
>
> Unless the assembler is redesigned to use just one expression processor,
> there will always be differences in between instruction operands and DC
> operands
>
I see little value in attempting to eliminate that difference
and much value in pr
Have you not seen the many prior discussions of this excruciating topic?
HLASM's hex notation is a PIA! 2s-complement is great for computers, not
much so for humans. HLASM treats all hex constants as a 32-bit number, so
if you need to specify a negative number in hex, you have to spell out all
3
Smith
Sent: Saturday, February 25, 2017 7:06 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
Have you not seen the many prior discussions of this excruciating topic?
HLASM's hex notation is a PIA! 2s-complement is great for computers, not
much so for humans. HLASM treats a
Exactly. HLASM is inconsistent in conflating storage types (F, H, etc.)
and data types (B, X, C), which definitely adds to the confusion. C
(and its derivatives) makes more sense in this regard. OTOH, C does
have the interesting feature that the size of ints (and shorts and
longs) and pointe
Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Smith
Sent: Saturday, February 25, 2017 11:24
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
Exactly. HLASM is inconsistent in conflating storage types (F, H, etc.) and
data types (B, X,
5 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
The ability to specify:
IIHF R00,H'12345,0'
to insert 12345 into bytes 0-1, and zero into bytes 2-3 of register would be
useful.
Kludge for this is:
IIHF R00,12345*65536
which is ugly, while:
IIHL R00, 809041920
is e
RV.UGA.EDU
Subject: Re: HLASM anomaly
Maybe a little less of a kludge using SETA arithmetic function SLL, but maybe
not:
LCLA &IIHFARG
&IIHFARG SETA SLL(X'01', 16)+X'2345'
IIHF R00,&IIHFARG
Being able to code the SETA argument in the instruction wo
ied using SETA functions directly as instruction operands, doesn't
> work.
>
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Farley, Peter x23353
> Sent: Monday, February 27, 2017 18:56
> To: A
On 2017-02-28, at 14:02, Melvyn Maltz wrote:
> To restate what I'm asking for...
> Now that we have 2 and 4-byte immediate values it would make sense
> to allow both duplication factor and explicit length for these
> Currently the instructions below would fail
> AHI 1,2X'FF'
> CFI
I did point out that the expression analyser is a 32 bit operand
processor - it does not know the origin or format of the original input,
it is just operating on the 32 bit values and only at the end is there
any consideration of the size of the target..
So at input, you might code any one of
List wrote on
28/02/2017 21:02:09:
> From: Melvyn Maltz
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 28/02/2017 21:02
> Subject: HLASM anomaly
> Sent by: IBM Mainframe Assembler List
>
> To restate what I'm asking for...
>Now that we have 2 and 4-byte immedia
On 3/1/17, Brent Longborough wrote:
> I really can't understand why we're making such an indigestible meal of
> all this.
>
> Take for example, AHI R1,2X'FF'. What does that even *mean*? If it
> *means* AHI R1,-1, then write it like that, so that the unfortunate
> programmer who has to maintain yo
LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
On 3/1/17, Brent Longborough wrote:
> I really can't understand why we're making such an indigestible meal
> of all this.
>
> Take for example, AHI R1,2X'FF'. What does that even *mean*? If it
> *means* AHI R1,-
> It is perhaps a silly example. But suppose R1 was to contain a pair
> of flag byte values. Suppose the flags were equated. Now it might
> make sense to code
>
> LHI R1,2AL1(MYFLAG1)
>
> Or something like that. Yes you can code the following but it is no
> great exemplar of coding clarity:
>
al Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Mark Boonie
Sent: Wednesday, March 1, 2017 7:53 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
> It is perhaps a silly example. But suppose R1 was to contain a pair of
>
> Were I to rebut each of your hypothetical objections you could of course
> rebut my rebuttals. I will only point out that often the coder does not
have
> control over how flags are defined: they are defined in some system or
> "external" DSECT or similar.
I concede that readily. My thinking wa
SSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
> Were I to rebut each of your hypothetical objections you could of
> course rebut my rebuttals. I will only point out that often the coder
> does not
have
> control over how flags are defined: they are defined in some system or
>
On 2017-03-01, at 10:00, Charles Mills wrote:
> For sure! It's not a problem I lose sleep over -- perhaps because my primary
> language is now C++, no longer assembler.
>
> I don't recall ever thinking about the issue until it came up on this list.
>
> I'm a "design elegance" guy. It would pleas
On 2017-03-01, at 00:03, John Dravnieks wrote:
>
> So if you code AHI 1,65535 then HLASM will give you this
>
> 00 A71A 0 2 ahi 1,65535
> ** ASMA320W Immediate field operand may have incorrect sign or magnitude
>
Should the Reference specify the effect
On 2017-03-01, at 12:06, John Walker wrote:
> This sounds like a C person trying to get Assembler to conform to C coding
> expectations. Is that a correct perception?
>
Or, just expecting consistent behavior throughout HLASM.
XEQU C'x'
LHI R1,X
ought to have the same behav
ASMA320W is imho, a total wimp-out on IBM's behalf. There'd be less
confusion if this was flagged as an *error*, which it is. It may sometimes
generate what the user wants, but the user didn't specify it correctly.
And the case where the assembler issues this for BR instructions is
egregiously w
On 2017-03-01, at 13:24, Steve Smith wrote:
> ASMA320W is imho, a total wimp-out on IBM's behalf. There'd be less
> confusion if this was flagged as an *error*, which it is. It may sometimes
> generate what the user wants, but the user didn't specify it correctly.
>
> And the case where the ass
ginal Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Wednesday, March 1, 2017 1:59 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
On 2017-03-01, at 13:24, Steve Smith wrote:
> ASMA320W is imho, a total wi
1:54
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
On 2017-03-01, at 10:00, Charles Mills wrote:
> For sure! It's not a problem I lose sleep over -- perhaps because my
> primary language is now C++, no longer assembler.
>
> I don't recall ever thinking ab
sembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU
> ]
> On Behalf Of Paul Gilmartin
> Sent: Wednesday, March 1, 2017 1:59 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: HLASM anomaly
>
> On 2017-03-01, at 13:24, Steve Smith wrote:
>
> > ASMA320W is imho,
On 2017-03-01, at 17:35, Ngan, Robert wrote:
> I noticed the new COBOL compiler was generating:
>
> MVHHI target,0
> MVHHI target+2,48000
>
> instead of:
>
> MVC target,=F'48000'
>
> and I thought I'd look into using 2 MVHHI's instead of a MVC with a literal
> even when the top half of the va
by 65536 gives C'F5' instead of C'F4'. However &M3
above generates the expected value.
Robert
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Paul Gilmartin
Sent: Wednesday, March 01, 2017 20:40
To: ASSE
On 2017-03-02, at 13:04, Ngan, Robert wrote:
> I was interested in the top half of the fullword, your equates give me the
> bottom half, which I do not need to do anything special for since HLASM
> truncates the value correctly when used directly on the MVHHI instruction.
>
Ah. I forgot a ste
On 5 March 2017 at 13:03, Paul Gilmartin
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> And 64-bit expressions. It's difficult to fully exploit a 64-bit
> architecture using a 32-bit language.
Do you think 64-bit expressions are really what's needed, or should it
be infinite-precisi
>
> In passing, I'm a little surprised not to have heard from either of
> the two commerical vendors of HLASM compatible cross-assemblers.
>
> Tony H.
>
Hi Tony,
We try to not get too involved with opinions.
I can say that mimic'ing the rather baroque methods
HLASM uses (likely for hi
Tony,
>> ... to have heard from either of the two commerical vendors of
>> HLASM compatible cross-assemblers.
Now I have seen one. What is the other (is there one?) ?
Martin Trübner; everything around "PoOps of z/arch"
On 2017-03-05, at 14:40, Martin Truebner wrote:
>
>>> ... to have heard from either of the two commerical vendors of
>>> HLASM compatible cross-assemblers.
>
> Now I have seen one. What is the other (is there one?) ?
>
Dignus, Tachyon, (does MicroFocus have one?), and the non-commercial
z390.
Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
>
> On 2017-03-05, at 14:40, Martin Truebner wrote:
> >
> >>> ... to have heard from either of the two commerical vendors of
> >>> HLASM compatible cross-assemblers.
> >
> > Now I have seen one. What is the other (is there o
On 06/03/2017 13:39, Thomas David Rivers wrote:
Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
On 2017-03-05, at 14:40, Martin Truebner wrote:
... to have heard from either of the two commerical vendors of
HLASM compatible cross-assemblers.
Now I have seen one. What is
Pieter Wiid wrote:
>
> Your USING should be USING X,R2
> Then, you get this with HLASM (z/OS 2.2)
>
>2 1 R2 EQU 2
>3 2 R3 EQU 3
> 000 4 3 FOO CSECT
> FF
On 2017-03-06, at 05:43, Thomas David Rivers wrote:
> Pieter Wiid wrote:
>>
>> Your USING should be USING X,R2
>>
Didn't I say earlier that I'm not an Assembler programmer?
>> Then, you get this with HLASM (z/OS 2.2)
>>
>> 2 1 R2 EQU 2
>>
> >
> > that means, for this bright Monday morning - I'll have to enter a bug.
> >
> But here, I disagree with HLASM's behavior and believe DASM is doing
> the right thing.
>
> Which bug will you enter?
>
> -- gil
>
The bug goes in with as "we aren't the same as HLASM".
It's surprising how
On 2017-03-06, at 07:04, Thomas David Rivers wrote:
>>>
>>> that means, for this bright Monday morning - I'll have to enter a bug.
>>>
>> But here, I disagree with HLASM's behavior and believe DASM is doing
>> the right thing.
>>
>> Which bug will you enter?
>
> The bug goes in with as "we aren
Ref: Your note of Mon, 6 Mar 2017 07:43:25 -0500
I noticed some time ago that HLASM fails to check properly for
overflow during USING calculations, which in my opinion is a bug
in HLASM. However, it's not just a matter of checking each
calculation for overflow, because intermediate calculations
nt: Monday, March 6, 2017 6:24 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
Ref: Your note of Mon, 6 Mar 2017 07:43:25 -0500
I noticed some time ago that HLASM fails to check properly for overflow
during USING calculations, which in my opinion is a bug in HLASM. However,
it&#x
On 2017-03-06, at 09:18, Charles Mills wrote:
> Hardware address arithmetic has always allowed overflow, right?
>
> I could load X'FFF0' into R1, do L R2,32(,R1) and get the CVT, right?
>
Not in AMODE 64. The example I gave was (slightly adjusted) to load
X'7FFF' into R1. Then I might
DU
Subject: Re: HLASM anomaly
On 2017-03-06, at 09:18, Charles Mills wrote:
> Hardware address arithmetic has always allowed overflow, right?
>
> I could load X'FFF0' into R1, do L R2,32(,R1) and get the CVT, right?
>
Not in AMODE 64. The example I gave was (slightly ad
On 2017-03-06, at 10:01, Charles Mills wrote:
> A detail, right? In AMODE 64 I could load X'FFF0' into R1, ...
>
You could, but that's not the example I gave. And you can't code
the USING. I'm disputing the operation not of the hardware but of
the USING instruction.
I don't know w
X'0010'.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Monday, March 6, 2017 9:11 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
On 2017-03-06, at 10:01, Charles M
On 2017-03-02, at 13:04, Ngan, Robert wrote:
> However, I can use your code to strip the low order half off the value before
> dividing by 65536, which resolves my issue of the value being potentially
> "off by one" when a negative value is divided.
> ...
> The example "expression" I was mess
It would seem to me that perhaps the instruction operand parser should be
re-evaluated, since it was probably originally written when all immediate
operands were no longer than 1 byte and then extended for 2 byte operands,
directed to the rightmost positions in the target register. (I am sure
: HLASM "Anomaly"
It would seem to me that perhaps the instruction operand parser should be
re-evaluated, since it was probably originally written when all immediate
operands were no longer than 1 byte and then extended for 2 byte operands,
directed to the rightmost positions in
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.
The
@LISTSERV.UGA.EDU
Subject: Re: HLASM "Anomaly"
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 bot
gt; Sent: Friday, March 17, 2017 3:45 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: HLASM "Anomaly"
>
> Melvyn Maltz has proposed that repeat counts should be allowed in
> immediate operands. Given that the modern instructions allow larger
> immediate operand
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.
Certain
Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Tom Marchant
Sent: Friday, March 17, 2017 2:09 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM "Anomaly"
On Fri, 17 Mar 2017 10:44:41 +, Martin Ward wrote:
>Given that 2X'FF' generate
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 restr
10, well we still do B *+10
It's 10 halfwords
I've also noticed that the HLASM output listing is very inconsistent about
immediate operands, when I've done further research I'll include it in my RFE
Melvyn Maltz.
- Original Message -
From: "Tom
0e4a59b-dmarc-requ...@listserv.uga.edu>
To:
Sent: Friday, March 17, 2017 11:15 PM
Subject: Re: HLASM "Anomaly"
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
On 2017-03-17, at 17:40, MELVYN MALTZ wrote:
>
> 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
>
For which of these intructions do you agree/disagree with
HLASM's behavior:
and W messages assemble
correctly, except the last LHI which has the invalid 2AL1...doh
Melvyn Maltz.
- Original Message -
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
To:
Sent: Saturday, March 18, 2017 2:10 PM
Subject: Re: HLASM "Ano
8 to +32767.
> - Original Message - From: "Paul Gilmartin"
> Sent: Saturday, March 18, 2017 2:10 PM
> Subject: Re: HLASM "Anomaly"
>
> For which of these intructions do you agree/disagree with
> HLASM's behavior:
> ...
> H2
Paul,
To my mind, X'' is also -1, which is in the halfword range.
Thus it merits a warning as the assembler cannot know whether the
X'' value of H5 is intended to be signed or unsigned.
Neither should it make any assumptions. So I'm entirely
fine with HLASM accepting the value and using i
be drawn to the Programmer's intent, did they mean
to code LGFI ?
Melvyn.
- Original Message -
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
To:
Sent: Saturday, March 18, 2017 10:21 PM
Subject: Re: HLASM "Anomaly"
On 2017-03-18,
Please don't reply with "Subject:...Digest..."
On 2017-03-20, at 17:45, Steve Smith wrote:
> Two's-complement is an amazingly great way for binary computers to store
> negative numbers. It is not so great for humans to read or write. First
> of all, you have to know where the sign bit is, and X
On 3/20/2017 20:58, Paul Gilmartin wrote:
Please don't reply with "Subject:...Digest..."
Sorry... I wish I remembered to do that, but I usually don't.
On 2017-03-20, at 17:45, Steve Smith wrote:
Two's-complement is an amazingly great way for binary computers to store
negative numbers. It is
scussed to death
Melvyn Maltz.
- Original Message -
From: "Steve Smith"
To:
Sent: Tuesday, March 21, 2017 2:18 AM
Subject: Re: HLASM "Anomaly"
On 3/20/2017 20:58, Paul Gilmartin wrote:
Please don't reply with "Subject:...Digest..."
Sorry... I wis
On 2017-03-21, at 11:03, MELVYN MALTZ wrote:
> Hi Steves, and Paul,
>
> Ok, I don't want this argument to get circular
>
Yet, here I am.
Why not just specify -1
> As in:
> CLI HERE,-1
>
No. You took a a well-reasoned statement of Steve's:
On 2017-03-20, at 20:18, Steve Smith wrote:
On 2017-03-20, at 20:18, Steve Smith wrote:
> On 3/20/2017 20:58, Paul Gilmartin wrote:
>> Please don't reply with "Subject:...Digest..."
> Sorry... I wish I remembered to do that, but I usually don't.
>>
>> On 2017-03-20, at 17:45, Steve Smith wrote:
>>
>>> Two's-complement is an amazingly grea
or not, but saying it
is half wrong (4 rather than 8) is just bailing on the decision.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Abe Kornelis
Sent: Sunday, March 19, 2017 12:22 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.E
On 2017-03-24, at 09:17, Charles Mills wrote:
>
> Warnings are not much better or different than errors. It sounds great to
> say "issue a warning" but the fact is that then the programmer has to either
> (a.) live with and ignore RC=4 for the life of the project; of (b.) change
> the code. If the
ST@LISTSERV.UGA.EDU
> Date: 03/24/2017 11:18 AM
> Subject: Re: HLASM "Anomaly"
> Sent by: IBM Mainframe Assembler List
>
> Apologies for the late reply. Outlook thought this was SPAM.
>
> Warnings are not much better or different than errors. It sounds great
ess!
Thank you for BEAR!
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Mark Boonie
Sent: Friday, March 24, 2017 13:39
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM "Anomaly"
One reason to implement the messages
On 2017-03-24, at 17:34, Ngan, Robert wrote:
> My "favorite" is the warning you get when the target of your JAS/BRAS shifts
> to an offset more that 64K from the instruction. You only get a ASMA320W
> warning (when would this not be an error?), and at execution time the
> truncated immediate of
Ref: Your note of Fri, 24 Mar 2017 23:34:21 +
This was fixed over a year ago. Since APAR PI34981 in early
2016, a relative immediate operand which is out of range gives
error message ASMA223E.
Robert Ngan wrote:
> My "favorite" is the warning you get when the target of your
> JAS/BRAS shift
Well, good news! That was a nasty little issue.
On Sat, Mar 25, 2017 at 5:48 AM, Jonathan Scott wrote:
> Ref: Your note of Fri, 24 Mar 2017 23:34:21 +
>
> This was fixed over a year ago. Since APAR PI34981 in early
> 2016, a relative immediate operand which is out of range gives
> error
My "favorite" is the warning you get when the target of your
JAS/BRAS shifts to an offset more that 64K from the instruction.
You only get a ASMA320W warning (when would this not be an error?),
and at execution time the truncated immediate offset branches you
to some arbitrary address!
Am I
Different PTFs
CharlesSent from a mobile; please excuse the brevity.
Original message From: Peter Relson Date:
3/25/17 11:16 AM (GMT-08:00) To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re:
HLASM "Anomaly"
My "favorite" is the warning you get when the
Regarding the lengthy discussion of immediate operands and whether there
should be warnings or errors, I will point out that there is next to zero
chance that the assembler will unconditionally change its rules in this
regard, as that could cause currently working JCL to fail (I'm with
Charles
On 2017-03-25, at 13:30, Peter Relson wrote:
>
> We often choose to live with the poor decisions that we might have made on
> initial implementation because compatibility is a huge strength of our
> platform.
>
But beware lest that platform collapse under the accumulated weight
of those compat
better than it does at present
Melvyn Maltz.
- Original Message -
From: "Peter Relson"
To:
Sent: Saturday, March 25, 2017 8:30 PM
Subject: Re: HLASM "Anomaly"
Regarding the lengthy discussion of immediate operands and whether there
should be warnings or errors,
16
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM "Anomaly"
My "favorite" is the warning you get when the target of your JAS/BRAS shifts to
an offset more that 64K from the instruction.
You only get a ASMA320W warning (when would this not be an error?), and at
execution tim
STSERV.UGA.EDU
> Date: 25/03/2017 07:34
> Subject: Re: HLASM "Anomaly"
> Sent by: IBM Mainframe Assembler List
>
> My "favorite" is the warning you get when the target of your JAS/
> BRAS shifts to an offset more that 64K from the instruction. You
> only
k of hard assembly-stopping ERROR diagnostics is probably due to
this light-touch approach of not wanting to break existing code, plus not
wanting to annoy all those old-timer's who love their coding tricks.
Craig Brookes
IBM Mainframe Assembler List wrote on
24/03/2017 23:55:31:
> Fro
1 - 100 of 101 matches
Mail list logo
