A working program had the following code:
018000 MVC 0(8,R1),=CL8'EJESPOP' Set command name
018010 MVC 8(8,R1),=CL8'PATHNAME'Set command parameter
An overzealous programmer, trying to be helpful, changed it to:
018000 MVC 0(16,R1),=CL8'EJESPO
on Ed Jaffe's posting:
Of course, there is no substitute for thorough testing. But, it occurs
to me that the assembler could issue a warning when data is lost from
truncation as the result of a nominal value requiring more bytes than
are explicitly specified via a length modifier.
Note: acco
From: "Ed Jaffe"
To:
Sent: Friday, May 01, 2015 8:23 AM
A working program had the following code:
018000 MVC 0(8,R1),=CL8'EJESPOP' Set command name
018010 MVC 8(8,R1),=CL8'PATHNAME'Set command parameter
An overzealous programmer, trying to be helpful, c
From: "Ed Jaffe"
To:
Sent: Friday, May 01, 2015 8:23 AM
A working program had the following code:
018000 MVC 0(8,R1),=CL8'EJESPOP' Set command name
018010 MVC 8(8,R1),=CL8'PATHNAME'Set command parameter
An overzealous programmer, trying to be helpful, ch
Ed,
Johns right - it is a reasonable request. Will you be raising an requirement
(RFE - http://www.ibm.com/support/docview.wss?uid=swg21577670) - either from
you directly or as a group request from SHARE ?
Sharuff
Cobol has messages for numeric truncation. Because they are warnings,
programmers tend to treat them as noise and ignore them.
I am very much spoiled by the colorful interfaces in ISPF edit now. They
show simple mistakes dramatically. Any interface that can show the error
in color at edit ti
On 2015-04-30, at 16:23, Ed Jaffe wrote:
> A working program had the following code:
>
> 018000 MVC 0(8,R1),=CL8'EJESPOP' Set command name
> 018010 MVC 8(8,R1),=CL8'PATHNAME'Set command parameter
>
> An overzealous programmer, trying to be helpful, changed i
Seems to me what would be nice is a way to use the length of the
second operand as the length for MVC or CLC.
If you are copying into a buffer, it is the length of the source,
not the length of the buffer, that you want to use.
Once you do that, the given problem goes away.
(You might then want
On 2015-05-01, at 10:09, glen herrmannsfeldt wrote:
> Seems to me what would be nice is a way to use the length of the
> second operand as the length for MVC or CLC.
>
> If you are copying into a buffer, it is the length of the source,
> not the length of the buffer, that you want to use.
>
Th
Very easy macro to write. Good one for beginners learning macros. I
remember writing one of those about 4 decades ago, give or take. I have
recreated it everywhere I worked.
Richard Kuebbing
IBM Mainframe Assembler List wrote on
05/01/2015 12:09:20 PM:
> From: glen herrmannsfeldt
>
> Se
From: "John Walker" <00c645a0d640-dmarc-requ...@listserv.uga.edu>
Sent: Friday, May 01, 2015 9:00 PM
Probably somebody saw the need to add in the code and didn't think about how
silly it looked.
Unlikely.
If it was a timid approach, the obvious thing would have been to extend
the existin
The modified statement is, of course, a blundering one. The modifier's
zeal outran his skills.
Still, it seems to me that situations like this one in which 1) an explicit
length is provided and 2) there is a mismatch between this length and that
of the literal involved should be noted by the asse
This is what came to my mind, too.
We are talking about this ASSEMBLER or machine instruction:
MVC 0(16,R1),=CL8'EJESPOP PATHNAME' Set cmd name/parm
which, IMO, could be diagnosed as containing a possible run time error
at assembly time.
Others, which sometimes occured to me, and which I had
From: "glen herrmannsfeldt"
Sent: Saturday, May 02, 2015 2:09 AM
Seems to me what would be nice is a way to use the length of the
second operand as the length for MVC or CLC.
Definitely not.
But a macro could be written to deal with the general case.
If you are copying into a buffer, it i
EJ's original suggestion was a good one; and it may well be that, as Bernd
Oppolzer has suggested, he identified one of a class of quondam
errors/blunders that the assembler can usefully warn against.
More attention to this narrow question may yet yield something useful.
On Fri, May 1, 2015 at 10
A good idea, but the HLASM should not warn on zero lengths coded in MVCs
that are EX targets:
MOVIT MVC 0(0,R1),=CL16'' >>
Executed <<
Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.
No change to mvc is needed. The warning is for character constants with
explicit length.
On May 2, 2015 2:28 PM, "Mike Shaw" wrote:
> A good idea, but the HLASM should not warn on zero lengths coded in MVCs
> that are EX targets:
>
> MOVIT MVC 0(0,R1),=CL16''
MVC short,=256c' '
MVC longer,=256c' '
MVC full,=256c' '
SHORTDSCL5
LONGER DS CL120
FULL DS CL256
On Sat, 2 May 2015 21:26:02 -0400 Steve Smith wrote:
:>No change to mvc is needed. The warning is for character constants with
:>explici
IMO, these examples are not as pathologic as the examples that
Ed Jaffe and I provided, because in Ed's and my examples, the
MVC took garbage bytes behind the literal constant and moved them
to the target. Same goes for my examples with ST vs. STH and N.
So I believe these examples should be trea
From: "Bernd Oppolzer"
Sent: Sunday, May 03, 2015 9:19 PM
BTW: In PL/1, for example, you can activate the STRINGSIZE condition
to deal with such situations (source string longer than target), but the
default action, AFAIK, is: writing a message to SYSPRINT and continue,
so this is not consider
From: "Mike Shaw"
Sent: Sunday, May 03, 2015 4:28 AM
A good idea, but the HLASM should not warn on zero lengths coded in MVCs
that are EX targets:
But such an MVC can have a non-zero length. The EX instruction
ORs together the LS 8 bits of the register with the 8 bits in the second byte
of
a.edu] On Behalf Of robin
> Sent: Sunday, May 03, 2015 7:36 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Option to Prevent Data Loss Due to Truncation of Nominal Value
>
> From: "Mike Shaw"
> Sent: Sunday, May 03, 2015 4:28 AM
>
>
> >A good id
I don't know what your point is.
There are uncountable ways to make errors in assembly language not
available to HLL coders. HLASM is *not* a compiler. One could be made,
with whatever features one thought desirable, including strong typing, and
whatever rules one liked in regards to string leng
You are right, of course; in the original example, there would be no error,
if the explicit length on the literal had not been specified.
That is:
MVC 0(16,R1),=CL8'EJESPOP PATHNAME' Set cmd name/parm
the problem is the CL8 which was left there when the co-worker of Ed Jaffe
changed the liter
lt of the OR is, of course, what the programmer
intended.
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
l...@listserv.uga.edu] On Behalf Of robin
Sent: Sunday, May 03, 2015 7:36 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Option to Prevent Data Loss Due t
At 11:35 -0700 on 05/03/2015, retired mainframer wrote about Re:
Option to Prevent Data Loss Due to Truncation of Nomina:
But the fact that some bits are already set means the result of the
OR could have a different value than the LSB of the register,
resulting in more bytes being moved than d
Much of this discussion seems to illustrate a risk in using character
literals: it's difficult to refer explicitly to their length attribute.
One could write
MVC Target(L'=C'very long string'),=C'very long string')
hoping you made the two instances identical. It seems preferable to me t
John Ehrman has made the crucial point. Character terms are problematic
My personal preference, predictably, is to use the facilities of the macro
language. Once a character set symbol has been defined all of that
language's facilities for concatenation, substring construction, and
character co
28 matches
Mail list logo
