Ref: Your note of Mon, 15 Feb 2021 09:27:13 -0700 gil wrote: > Someone wrote here recently of using Binder then AMBLIST > as an alternative to (paying for?) ASMDASM. Would the easiest > enhancement for ASMDASM be to invoke Program Management > internally to obtain the information?
ASMDASM already has access to the ESD attribute information in each of the many separate routines for all the various different types of program that it can read. (It supports OBJ sequential files, GOFF sequential files, PDS load modules, PDSE program objects, CMS MODULE, VSE librarian object files, VSE librarian phases and anything else which I've forgotten). However, the current interface area used to return the ESD information from those subroutines to the common code doesn't include space for the ESD flags which include AMODE, RMODE and the RSECT flag. So all of those routines would need to be changed to support returning the ESD flags, then the common code would need to be enhanced to generate the relevant statements. So it's a known requirement (the first one in the internal list against ASMDASM) and we think we know how to implement it, but it requires non-trivial changes to currently very stable code, plus extensive testing, and it is usually easy enough to add the relevant statements by hand when fixing up other stuff. If anyone feels there is a particularly strong justification for implementing it sooner rather than later, please feel free to raise an RFE with the appropriate information. Jonathan Scott, HLASM IBM Hursley, UK
