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. > >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. >...phsiii (grumpy after wasting time on this) > Me grumpy? No, I'm merely sarcastic. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
