Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Lousy error from HLASM in USS
142 views
Skip to first unread message
Phil Smith III
Apr 11, 2019, 7:48:13 PM4/11/19
to
Easy to reproduce. Create an assembler input deck with a line longer than 80 bytes; it can even be a single line:
* x
(that x is in column 81)
Put it in a USS directory as, say, bad.asm. Now cd to that directory in a shell and issue:
as ./bad.asm
You'll get this lovely error:
as ./bad.asm
** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on SYS00011 data set
,PHS3 ,*OMVSEX ,OMVS,*,SYS00011,GET ,WRONG LEN RECRD,00000000000000,QSAM S
,***,*******,0000000001,0008002C, ,**,
FSUM3401 The assemble step ended with rc = 20.
Really? That's somebody's idea of a coherent error? After much tinkering, it turns out that WRONG LEN RECRD means "I found a record too long" (was there a shortage of capital Os that day?), and in
,***,*******,0000000001,0008002C, ,**,
the 0000000001 is the offending record number.
Needless to say, we did not find this on record 0000000001 of a bogus assembler file. Instead, we found it on record n of an included macro, which took far longer to track down. And yes, the number shown in that case is the record number *of the included macro*, whose name appears nowhere in the error. So the error isn't even correct in that case, as it appears to be saying that record n of the input file is wrong, when it's actually record n of the included macro, which of course could be many layers deep.
Errors, kids, should be illuminating. In this case, it knew everything it needed to: the offending macro name, the offending record number, and what was wrong with it. It could have just said that, but no, it had to be obscure.
I'll admit that this is no worse than a lot of z/OS errors. That's no excuse; this isn't 1964.
...phsiii (grumpy after wasting time on this)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
* x
(that x is in column 81)
Put it in a USS directory as, say, bad.asm. Now cd to that directory in a shell and issue:
as ./bad.asm
You'll get this lovely error:
as ./bad.asm
** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on SYS00011 data set
,PHS3 ,*OMVSEX ,OMVS,*,SYS00011,GET ,WRONG LEN RECRD,00000000000000,QSAM S
,***,*******,0000000001,0008002C, ,**,
FSUM3401 The assemble step ended with rc = 20.
Really? That's somebody's idea of a coherent error? After much tinkering, it turns out that WRONG LEN RECRD means "I found a record too long" (was there a shortage of capital Os that day?), and in
,***,*******,0000000001,0008002C, ,**,
the 0000000001 is the offending record number.
Needless to say, we did not find this on record 0000000001 of a bogus assembler file. Instead, we found it on record n of an included macro, which took far longer to track down. And yes, the number shown in that case is the record number *of the included macro*, whose name appears nowhere in the error. So the error isn't even correct in that case, as it appears to be saying that record n of the input file is wrong, when it's actually record n of the included macro, which of course could be many layers deep.
Errors, kids, should be illuminating. In this case, it knew everything it needed to: the offending macro name, the offending record number, and what was wrong with it. It could have just said that, but no, it had to be obscure.
I'll admit that this is no worse than a lot of z/OS errors. That's no excuse; this isn't 1964.
...phsiii (grumpy after wasting time on this)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
Apr 11, 2019, 9:01:18 PM4/11/19
to
That should have been cross-posted to ASSEMBLER-LIST and MVS-OE.
On Thu, 11 Apr 2019 19:47:56 -0400, Phil Smith III wrote:
>Easy to reproduce. Create an assembler input deck with a line longer than 80 bytes; it can even be a single line:
>* x
>(that x is in column 81)
>Put it in a USS directory as, say, bad.asm. Now cd to that directory in a shell and issue:
>as ./bad.asm
>
>You'll get this lovely error:
>as ./bad.asm
>** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on SYS00011 data set
> ,PHS3 ,*OMVSEX ,OMVS,*,SYS00011,GET ,WRONG LEN RECRD,00000000000000,QSAM S
>,***,*******,0000000001,0008002C, ,**,
>FSUM3401 The assemble step ended with rc = 20.
>
That's from SYNADAF. I'm very familiar with it. That doesn't mean I like it.
You can get much the same in batch JCL with IEBGENER SYSUT1.
>Really? That's somebody's idea of a coherent error? After much tinkering, it turns out that WRONG LEN RECRD means "I found a record too long" (was there a shortage of capital Os that day?), and in
>,***,*******,0000000001,0008002C, ,**,
>the 0000000001 is the offending record number.
>
That message format was designed when storage was a million times
as expensive as today. But to change it might conflict with automated
operations, or not fit in LRECL=121.
>Needless to say, we did not find this on record 0000000001 of a bogus assembler file. Instead, we found it on record n of an included macro, which took far longer to track down. ...
>
Macro? the command you cited seems to show it as primary input.
SYS00011? I'd expect SYSIN or SYSLIB. Does "as" invoke HLASM with
an alternate DDNAME list?
> ... And yes, the number shown in that case is the record number *of the included macro*, whose name appears nowhere in the error. So the error isn't even correct in that case, as it appears to be saying that record n of the input file is wrong, when it's actually record n of the included macro, which of course could be many layers deep.
>...phsiii (grumpy after wasting time on this)
>
Me grumpy? No, I'm merely sarcastic.
-- gil
On Thu, 11 Apr 2019 19:47:56 -0400, Phil Smith III wrote:
>Easy to reproduce. Create an assembler input deck with a line longer than 80 bytes; it can even be a single line:
>* x
>(that x is in column 81)
>Put it in a USS directory as, say, bad.asm. Now cd to that directory in a shell and issue:
>as ./bad.asm
>
>You'll get this lovely error:
>as ./bad.asm
>** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on SYS00011 data set
> ,PHS3 ,*OMVSEX ,OMVS,*,SYS00011,GET ,WRONG LEN RECRD,00000000000000,QSAM S
>,***,*******,0000000001,0008002C, ,**,
>FSUM3401 The assemble step ended with rc = 20.
>
You can get much the same in batch JCL with IEBGENER SYSUT1.
>Really? That's somebody's idea of a coherent error? After much tinkering, it turns out that WRONG LEN RECRD means "I found a record too long" (was there a shortage of capital Os that day?), and in
>,***,*******,0000000001,0008002C, ,**,
>the 0000000001 is the offending record number.
>
as expensive as today. But to change it might conflict with automated
operations, or not fit in LRECL=121.
>Needless to say, we did not find this on record 0000000001 of a bogus assembler file. Instead, we found it on record n of an included macro, which took far longer to track down. ...
>
Macro? the command you cited seems to show it as primary input.
SYS00011? I'd expect SYSIN or SYSLIB. Does "as" invoke HLASM with
an alternate DDNAME list?
> ... And yes, the number shown in that case is the record number *of the included macro*, whose name appears nowhere in the error. So the error isn't even correct in that case, as it appears to be saying that record n of the input file is wrong, when it's actually record n of the included macro, which of course could be many layers deep.
>
>Errors, kids, should be illuminating. In this case, it knew everything it needed to: the offending macro name, the offending record number, and what was wrong with it. It could have just said that, but no, it had to be obscure.
>
>I'll admit that this is no worse than a lot of z/OS errors. That's no excuse; this isn't 1964.
>
But it must remain compatible with 1964.
>Errors, kids, should be illuminating. In this case, it knew everything it needed to: the offending macro name, the offending record number, and what was wrong with it. It could have just said that, but no, it had to be obscure.
>
>I'll admit that this is no worse than a lot of z/OS errors. That's no excuse; this isn't 1964.
>
>...phsiii (grumpy after wasting time on this)
>
-- gil
Steve Smith
Apr 12, 2019, 9:24:04 AM4/12/19
to
I think the grumpiness and sarcasm might be a bit over the top. The error
does have roots going back to the middle ages, that when combined with
modern functionality, causes some odd results. Anyway it's something that
doesn't happen very often. If IBM thinks it's worthwhile, they'll improve
it. I doubt there's any reason to worry about error message compatibility.
sas
does have roots going back to the middle ages, that when combined with
modern functionality, causes some odd results. Anyway it's something that
doesn't happen very often. If IBM thinks it's worthwhile, they'll improve
it. I doubt there's any reason to worry about error message compatibility.
sas
Paul Gilmartin
Apr 12, 2019, 12:56:54 PM4/12/19
to
On Fri, 12 Apr 2019 09:23:40 -0400, Steve Smith <sas...@GMAIL.COM> wrote:
>I think the grumpiness and sarcasm might be a bit over the top. The error
>does have roots going back to the middle ages,
>
IBM should operate a booth at Renaissance Faire. Or Comic Con.
>I think the grumpiness and sarcasm might be a bit over the top. The error
>does have roots going back to the middle ages,
>
> ... that when combined with
>modern functionality, causes some odd results. Anyway it's something that
>doesn't happen very often. If IBM thinks it's worthwhile, they'll improve it.
>
That would be an RFE. As new facilities such as zFS appear it happens
>doesn't happen very often. If IBM thinks it's worthwhile, they'll improve it.
>
increasingly often.
> ... I doubt there's any reason to worry about error message compatibility.
>
I'm staying with my assumption that the message is formatted by SYNADAF.
SYNADAF is admirable; it's reusable code. Not every facility needs to write
its own diagnostic formatter. But wide use engenders wide exposure to
incompatibility. How many callers make assumptions about SYNADAF message
format? Probably nonzero. In:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad500/syndf.htm
The SYNADAF macro uses register 1 to return the address of an area containing
a message. The message describes the error, and can be printed by a later PUT,
WRITE, or WTO macro. The message consists mainly of EBCDIC information and
is in variable-length record format. The format of the area is shown following the
descriptions of the SYNADAF parameters.
I assume that's Y(count),X'0000',up to 32,752 bytes of message text.
What callers would suffer overruns copying an unexpectdly long message into a
static buffer? Would some simply attempt to PUT it, as returned, to SYSTERM
and trigger a cascade of similar errors?
Regardless, it's lousy, and should be fixed. As reusable code, not only for HLASM.
-- gil
0 new messages