Jonathan, Possibly not a " sensible use of development resources", but that is an IBM decision I guess. I would say instead that a SYNAD exit on READ/GET from SYSIN and SYSLIB are in fact sensible uses of development resources rather than letting a generic SYNAD condition abend the assembly step, in order to provide the end user with better and more source-friendly error message information.
A sensible READ/GET SYNAD exit would know it was being invoked for a READ/GET I/O error and would presumably have better access to the state information of the assembly, like where in which file it happened (at least last record number and current file information). One could make the same statement for SYSPRINT / SYSTERM and other output WRITE/PUT routines for a SYNAD exit that knew it was being invoked for a WRITE/PUT error and for which class of output (print, terminal, ADATA, SYSLIN, SYSPUNCH). It just seems to me that a generic "OOPS" SYNAD abend routine is a lazy solution. Easy, but lazy. Even a generic "OOPS" SYNAD abend routine should be able to find current assembly state information related to the DD for which the error occurred. Where and how to report that information certainly needs care, but the information location should be available, via name/token service if necessary. Peter -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Jonathan Scott Sent: Monday, April 15, 2019 11:02 AM To: [email protected] Subject: Re: Lousy error from HLASM in USS Ref: Your note of Mon, 15 Apr 2019 14:57:34 +0000 Shmuel (Seymour J.) Metz writes: > That's how it's coded, not how it has to be coded. There's no reason > that the common error routine couldn't produce an equivalent of ASMA435I . The reason is that it would add unnecessary complexity and risk to a piece of code which is already having to handle a "should not occur" situation and hence has to be very cautious about what it can assume. The common SYNAD routine merely obtains the SYNAD information and terminates HLASM with the corresponding message. It also picks out the DDNAME from the message buffer. The abort routine has some logic to check whether SYSPRINT or SYSTERM is available for writing out the message and if not it uses WTO. The abort routine has no awareness of what was being done when the I/O error occurred, which could be before the start of the assembly, during the first pass, the interlude or the second pass, after the end, or anywhere else. If an I/O error occurs, control does not return to the I/O caller, as that would require I/O handling logic on every type of I/O function. It would obviously be theoretically possible to establish progress flags to enable a more specific diagnostic, but I wouldn't vote for that as a sensible use of development resources. > BTW, does HLASM display the second line of SYNADAF when the "S" > indicator is there? HLASM has had code to check for the 'S' indicator at +127 and issue the additional message since about 1998. I hope it works! Jonathan Scott, HLASM IBM Hursley, UK -- This 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.
