One reason to implement the messages as warnings instead of errors is that warnings can be suppressed, using options like SUPRWARN, TYPECHECK, FLAG, ALIGN, USING(WARN()), and maybe others. Some of these warnings can also be suppressed "locally" using ACONTROL. I'm not aware of any errors that can be suppressed, and I suspect that that is intentional.
Hopefully whatever proposal is submitted to IBM won't ask for existing warnings to be removed. - mb IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> wrote on 03/24/2017 11:17:02 AM: > From: Charles Mills <charl...@mcn.org> > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 03/24/2017 11:18 AM > Subject: Re: HLASM "Anomaly" > Sent by: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> > > Apologies for the late reply. Outlook thought this was SPAM. > > Warnings are not much better or different than errors. It sounds great to > say "issue a warning" but the fact is that then the programmer has to either > (a.) live with and ignore RC=4 for the life of the project; of (b.) change > the code. If the former then why issue the warning at all; if the latter > then it is no better or different than an error. I think warnings in this > situation are kind of wishy-washy: either it's wrong or it's not. I get the > difficulty in deciding whether LHI 0,X'FFFF' is wrong or not, but saying it > is half wrong (4 rather than 8) is just bailing on the decision. > > Charles
