>Really? That's somebody's idea of a coherent error? Actually, yes, but IMHO it is incomplete; it should include the dsname, member and path, as relevant.
I do see a documentation issue: the description of ASMA999U in HLASM Programmer's Guide should include a reference to, e.g., z/OS DFSMS Macro Instructions for Data Sets, for the format of the SYNADAF data. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Phil Smith III <[email protected]> Sent: Friday, April 12, 2019 11:28 PM To: [email protected] Subject: Lousy error from HLASM in USS (I'd posted this to IBM-MAIN; folks there quite reasonably said "You should have posted this to the assembler list, so here I am.) 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)
