Martin, you should always be free to design your own implementation if you desire. I don't think the point at which the data is collected is at issue here but more the data format. What you are suggesting is still each tool provider doing it on their own resulting in incompatible data being maintained for each tool. If there is a reduced data set that could be used by multiple tools, then the user would not have to maintain the larger ADATA data sets and the tools could read the common reduced data. This would result in one copy of the published data format instead of one copy per tool with a proprietary format.
Of course, the provided data would have to contain the data desired by all tools and perhaps that's what John is trying to prevent. If he provides a published data format or API then he may have to entertain requirements for changes to what he provides and it could make future enhancements more difficult than it would be for a private format. There is always trade-offs. It would benefit the tool providers and users but possibly add work for the data provider. Chuck Arney Arney Computer Systems -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Martin Truebner Sent: Tuesday, November 06, 2012 9:18 AM To: [email protected] Subject: Re: ASMLANGX files Chuck et al, Here is how I see it: I use the ADATA data and extract what I need and combine everything into a structure suitable for just me at compile-time (ADATA-exit). There is almost no extra processing at execution time of the program that needs debugging. The ADATA is the HLASM-data as in the ASMLANGX-files but packaged and prepared for external users. If you are uncertain about a certain piece of information, then you need everything.... My point is: Reduce the data at compile via an ADATA-exit and if a new version needs more data- recompile it with the new version and offer reduced functionality without recompile. My opinion. YMMV -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
