It is great to see that an enhancement has been implemented for ChangeMan ZMF to detect assembler macros within assembler programs.  This will definitely help ensure that the latest version of an assembler macro gets included during a build of an assembler program, much like has been the case for assembler copybooks for years prior.

However, I do see an opportunity to consolidate code within CMN$$ASM and CMN$$HLA together, and keep it in the traditional CMN$$ASM ISPF skeleton.  The advantage of this is that doing any ChangeMan ZMF upgrade, there is potential for less components to retrofit.  (As an example, take a look at CMN$$COE, which has been set up to handle COBOL compiles with a separate CICS translate and DB2 precompile, and also COBOL compiles that use the integrated CICS translated and DB2 co-processor.  CMN$$ASM can be set up to handle both ADATA and non-ADATA scenarios...much like CMN$$WPP is already doing this.)

I suppose that CMNASM and CMNHLASM can be kept separate, but there is also opportunity to consolidate the code within CMNHLASM into CMNASM.  If this is done, then the &ADATA ISPF variable can be described and initialized within CMN$$VAR (and additionally controlled based on additional logic within CMN$$VAR and/or other in-house created VAR$appl ISPF skeletons), and then CMNASM would "know" when to include CMN$$WRT in the ISPF file tailoring or not.

I'm not sure what the initial customer requirements were with setting-up to handle detection of assembler macros, and it may very well asked by the customer to have a separate CMNASM and CMNHLASM.  However, this seems unnecessary because CMNHLASM, along with CMN$$HLA, would be another couple of separate ISPF skeletons that would need to potentially be maintained.  At the very lease, it seems like consolidation of logic found in CMN$$HLA can be put into CMN$$ASM.