Why do you consider an I/O error a "should not occur" situation rather than an expected exception? Why can't HLASM provide footprints for the error routine to use for a context message?
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Jonathan Scott <[email protected]> Sent: Monday, April 15, 2019 11:01 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
