Ref: Your note of Mon, 18 Mar 2013 09:03:18 -0500 I agree that management of the opcode name space is difficult, and I've been looking at ways to improve it from long before I joined the HLASM team. The mnemonic suffix system with :ASM or :MAC helps a bit, but I think systematic use of OPSYN and the right OPTABLE level covers a lot of cases. It might be nice to have a better way to push and pop OPSYN definitions to make it more modular.
Machine instructions (especially with extended mnemonics) are now up to 7 characters, and there's no guarantee that the hardware people won't increase them to 8 in future, so the old rule of thumb to use longer macro names to avoid conflicts is no longer very reliable. I would however recommend using a systematic prefix for packages of related macros where possible. All I/O from HLASM itself is current handled via a very general cross-platform interface, using either built-in platform specific routines or exit routines. As you can see in the Programmers Guide, at present there is no function in these I/O interfaces to scan the directory of a library, and the current routines do not even require there to be a concept of a "directory" for macros and copy books. This means that the idea of checking what macros exist in advance would require non-trivial changes to the I/O infrastructure. One thing which could be provided quite easily is a utility program to check the HLASM instruction mnemonics for a given OPTABLE level against the list of members in an arbitrary SYSLIB concatenation to warn about any potential conflicts. Is there any interest in this idea? In my case, such a scan might find quite a few macros which I wrote specifically to emulate newer instructions when code is assembled with an OPTABLE that doesn't support them, and I would not want those macros to be used when the real instructions were available. Jonathan Scott HLASM Development, IBM Hursley, UK
