> would be a further assault on the design integrity of OS/360's I/O > abstraction.
That train left town half a century ago. The I/O abstract is severely lacking in orthogonality, e.g., ASCII translation. Nor did it end with OS/360; unlike OS/VS1, MVS is missing CI and RCI so that you can't use an ACB for PS or a DCB for VSAM. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Charles Mills <[email protected]> Sent: Monday, April 15, 2019 10:19 PM To: [email protected] Subject: Re: Lousy error from HLASM in USS +1CharlesSent from a mobile; please excuse the brevity. -------- Original message --------From: "Farley, Peter x23353" <[email protected]> Date: 4/15/19 11:53 AM (GMT-08:00) To: [email protected] Subject: Re: Lousy error from HLASM in USS I disagree here. It is not "concealing it in HLASM" to know what line number of what COPY/MACRO member of what DSN generated the error. HLASM knows that information and only needs to send it out in its failure message. DFSMS knows nothing of how or why HLASM reads its inputs, only HLASM knows that.Plus only HLASM knows the COPY/MACRO nesting history and can (well, it could) trace back to the original source line that resulted in the error. I would argue that this a valid error reporting function that only HLASM can perform.For inspiration, look at the way that gcc reports #include errors, chaining up the #include tree to the base source file.Peter-----Original Message-----From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Paul GilmartinSent: Monday, April 15, 2019 1:37 PMTo: [email protected]: Re: Lousy error from HLASM in USSOn 2019-04-15, at 09:17:09, Seymour J Metz wrote:>> SYNADAF provides the DDname, which is sufficient> > Not when the dataset is dynamically allocated. I would not expect the OP to have a clue what dataset SYS00001 is.> That said, I consider this to be a case of missing information rather than an issue with the data in the message; what needs clarification is the referent of "WRNG.LNTH.RECRD"; IMHO changing the text to "Wrong Length Record" would serve no purpose.> The clarification (as you suggested earlier) exists in: https://secure-web.cisco.com/1lLpDSTyTMKugt0dObAJgSpcbgdKwBvhqusrSvZ1QMJqe3bnkDZCnmQAu8nMpTPM4NBzW3EIDqq8M-rpM9DsNW85PvppXjXnM2sSI_GvaXhHLYK_UdtcBlWF8PhIROxc_IQRhydYmqF1JbOrD_SxaM150Rv-CCys6_xCTLEsoYK0RwKhbDvgzQTltQ7FkZyUKJtxfj9OuvlEW0tlWVU4o0OOQAKcqtSfnPJfB8PDaFpkq0-0sU3eJ5DG1DdJXEAsEasTW-J4zKNG2JTTnmeHLBcoZq7ro5SPjQGGxKKR6mwseIEzfuaDCYes6odkfG24TPnyTaSd7CeCW9aS1kItByDgCQqoEE2ihhMgqfOIlNCVsa7g58fppYAe5rb2I9Hhh394S2yIEokABt0C54jQLvdH6ZwKaTdj-qyRMHlVpaPwgAsMYEcdEHGTTKzgJqCK3/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.idad500%2Fxmbf.htm... but this an endemic deficiency, and concealing it in HLASM would be a further assault on the design integrity of OS/360's I/O abstraction.The deficiency should be remedied in DFSMS, not HLASM, and should be extensible to provide for unforseen future enhancements in DFSMS.I'll suggest an alternatuve SYNADAX call that returns a pointer to an XML string with no specified maximum length, perhaps reasonably formatted with use of vertical and linear white space.-- gilThis message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
