<snip>There are indeed some limitations on macro keyword values, but an increasing proportion of macros have been coded or modified to support lower case values.</snip>
I have never seen a z/OS-provided macro that uses UPPER for such things as the MF value. <snip>What are your coding standards for HLASM (or PLS) with regards to lowercase? You both advocated lowercase comments. Are labels, instructions and operands also in lowercase? It's been a very long time but I thought there were problems with macros where mf=l failed but mf=L was acceptable. Are you coding uppercase char constants using DC CU'xxx' instead of DC C'xxx' to guarantee they are uppercase?</snip> I can tell you what I found most effective for reading the code: mixed-case for anything that makes sense (such as variable names, even long macro names, but not opcodes, and not specific values, such as "L" within MF=L). I do not use all-lowercase. I never used "DC CU'xxx'". <snip>You're not allowed to lowercase all comments because that introduces unacceptable risk and you lose the line change identifier (PTF) by ptf identifier. I've never seen lowercase comments because of most people don't want to see a hodgepodge of uppercase / lowercase comments. </snip> I hope I never talked about "lowercase". I talked about using mixed case. And the notion of "unacceptable risk" might be thought to apply less to development work than to service work. Making a module more readable could be thought to be worth the risk. I don't know why you would change the change identifier. I would not do so. Your notion of "most people" might be skewed. In my view "most people" will take what they can get. There's a compromise between doing the work to change existing stuff versus having a "hodgepodge" when new stuff follows a different/better approach. <snip>After all these years, there are still macros that do not fully support mixed case.</snip> I know of no macro provided by the MVS element of z/OS that "fully" supports mixed case in assembler. This probably has to do with the fact that "UPPER" has not "always" been available for use, coupled with the fact that the tooling that creates a lot of the macros was written before UPPER was available and has never been changed to use it. There has never been sufficient business reason to make the investment. It would not have been as simple as adding UPPER(...) around various things in part because of the possibility of a line now becoming too long and having to deal with that within a tool. Peter Relson
