In my case it gets an addressability error.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Assembler List on behalf
of Joseph Reichman
Sent: Wednesday, May 1, 2024 11:25
While WAD often means BAD, that is not always the case.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Assembler List on behalf
of Steve Smith
Sent: Wednesday, May 1, 2
No, it is a feature of *some* interpreters. Others translate into an internal
code and interpret that.
I don't know how it handles duplicate labels, but Object Rexx definitely
catches some errors that others don't as the result of its initial tokenization
prior to execution.
--
Shmuel (Seymou
Charles, all,
That type of error also occurs within HLASM when it is processing macro
code.
some errors are caught only if the pertinent statement is actually executed.
It hit me so many times that we implemented a non-compatible feature in z390
to do a better job at early error detection. I have
We used to call them "undocumented features." 😊
Bill Hitefield
> -Original Message-
> From: IBM Mainframe Assembler List
> On Behalf Of Steve Thompson
> Sent: Wednesday, May 1, 2024 1:45 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: ASMA043E Previously defined symbol
Well, and it is a feature of interpretive execution. When you branch to a
label, it looks until it finds that label. It doesn't keep looking to see if
there is another. (Yes, it could and might, but it would take time, and it
doesn't.)
It's an example of something I dislike about both Rexx and Pyt
One place I worked long ago used BAD: Broken as Designed.
Steve Thompson
On 5/1/2024 1:25 PM, Steve Smith wrote:
Ease of bizarre inscrutable errors is not the same as ease of use. Just
sayin' ;-)
WAD just means it was a bad design.
sas
On Wed, May 1, 2024 at 7:00 PM Phil Smith III wrote:
Ease of bizarre inscrutable errors is not the same as ease of use. Just
sayin' ;-)
WAD just means it was a bad design.
sas
On Wed, May 1, 2024 at 7:00 PM Phil Smith III wrote:
> Paul Gilmartin wrote, re Rexx being fine with duplicate labels:
> >That's bad.
>
> That's WAD. Remember, the goal o
Subsequent posts suggest you divined his intent better than I did. I know
Joao isn't a native speaker, and allow for that, but sometimes it doesn't
work.
sas
On Wed, May 1, 2024 at 6:59 PM Phil Smith III wrote:
> Steve Smith wrote:
> >It seems perfectly clear to me that the OP was asking why i
Paul Gilmartin wrote, re Rexx being fine with duplicate labels:
>That's bad.
That's WAD. Remember, the goal of Rexx was ease of use. Just sayin'.
Steve Smith wrote:
>It seems perfectly clear to me that the OP was asking why in this
>particular example, it only produced RC=4, instead of the expected RC=8.
>So far, no response seems to be relevant, other than the request for an
>example.
Oh. I did not get that at all; I took it as "I think t
On 5/1/24 09:53:45, Willy Jensen wrote:
REXX is fine with the same label occurring multiple times, it just picks the
first.
.
That's bad.
-Oprindelig meddelelse-
Fra: Charles Mills
Sendt: 1. maj 2024 17:47
I don't think that anyone has mentioned this point but I think that all
lan
One thing that has been requested is for the assembler to allow
duplicate EQU definitions provided that the value is the same.
However, this is not difficult to implement as a macro, for
example as follows:
Macro Define a value, tolerating duplicate
&name#equ &val
REXX is fine with the same label occurring multiple times, it just picks the
first.
Sample:
exit sub1()
Sub1: say 'first one';return 0
Sub1: say 'second one';return 0
Running the sample get message 'first one'
-Oprindelig meddelelse-
Fra: IBM Mainframe Assembler List
I just tested JNOP with a constant operand of "1" and the only issue is the
warning-level message which results in RC=04:
74 A704 0001149 JNOP 1
** ASMA056W Absolute value found when relocatable value expected - 1
IMHO that's not so bad that it should have been
I don't think that anyone has mentioned this point but I think that all
languages with which I am familiar (and that support data declarations of some
sort) behave the same way. COBOL, C, etc. -- all prohibit duplicate (truly
duplicate, after qualification) labels, referenced or not.
Rexx does
There is a B2D2 there just the mask is zero
So it falls thru
> On May 1, 2024, at 11:06 AM, Pieter Wiid wrote:
>
> NOP translates to BC 0
>
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Wednes
Just for comodity and I can't see a reason for this error.
Eventually I use to remember new updates with the actual date or my name
for example. And using the column one for that is easier.
Em qua., 1 de mai. de 2024, 08:09, Steve Smith escreveu:
> OK, that could be done. It would potentially g
As NOP is not a branch, I would not expect NOP to be converted
by IEABRC.
It is true that NOP has an address operand. If NOP is executed
using EX with a suitable mask in the register it can be used for
execution purposes, although this is rather obscure.
However, as the address operand is not no
NOP translates to BC 0
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Paul Gilmartin
Sent: Wednesday, 01 May 2024 16:21
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: IEABRC anomaly
On 5/1/24 07:56:17, Seymour J Metz wrote:
>
On 4/30/24 15:55:55, João Reginato wrote:
.
The message “ASMA043E Previously defined Symbol” is always issued when an
already defined field is redefined, even if it is not referenced,
making the compiler end with error (return code 8).
.
Does "the compiler" (which?) improperly generate duplic
On 5/1/24 07:56:17, Seymour J Metz wrote:
It turns out that IEABRC does not convert NOP to JNOP. Is that a bug or a
feature?
.
Does NOP depend on a base register?
--
gil
It turns out that IEABRC does not convert NOP to JNOP. Is that a bug or a
feature?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
Simple? It's easy for you to say that without knowing how the assembler works.
You can't see that it would be additional code?
You haven't answered the questions as to why your program dies that.
Feel free to submit an idea to change the behavior. Be sure to include a
business justification. Don't
On Wed, 1 May 2024 10:53:41 +0100, Jonathan Scott
wrote:
>> "The result of C2A is the same as is obtained from
>> &value SETA C'charstring'
>> except that C2A give a zero result for null strings, and
>> does not pair apostrophes or ampersands before conversion."
>
>It's hard to tell wh
Joao,
From a theoretical standpoint you are probably right.
A duplicate definition could be flagged as a warning,
and an error message could be issued only when referencing it.
But this would not work for labels that are externalized.
Also, when producing/using Adata it would cause confusion.
An
OK, that could be done. It would potentially generate far more error
messages for essentially one error. I see no reason or value in that
approach. I also think most programmers would strongly object.
Do you have some reason for needing to define duplicate, yet unreferenced
symbols?
sas
On We
I can't see it as an additional code if it is already checking the
duplicates. It could only show an error where/when/if the duplicated field
is referenced. Simple
Em qua., 1 de mai. de 2024, 07:20, Steve Smith escreveu:
> Because it's an error whether referenced or not. Why should the assembl
Because it's an error whether referenced or not. Why should the assembler
add additional code to check that symbol isn't referenced?
I don't understand your last statement.
sas
On Wed, May 1, 2024 at 11:43 AM João Reginato wrote:
> Ok, I understand your point of view. But why show the duplic
> "The result of C2A is the same as is obtained from
> &value SETA C'charstring'
> except that C2A give a zero result for null strings, and
> does not pair apostrophes or ampersands before conversion."
It's hard to tell what the original writer (in the 1990s) had in
mind, but I would agr
Ok, I understand your point of view. But why show the duplicate as an
error if it is not referenced anywhere? It could be an error just in the
references.
Em qua., 1 de mai. de 2024, 03:46, Steve Smith escreveu:
> It seems perfectly clear to me that the OP was asking why in this
> particular ex
31 matches
Mail list logo
