I have written an ADATA Filtering Program that z/XDC customers can
use to reduce ADATA library sizes from 50% to 90%. It is available
now via maintenance (Z1D-1302A).
For more information, please see our Facebook page at
facebook.com/colesoftware.
Dave Cole REPLY TO: [email protected]
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658
At 12/12/2009 10:18 AM, Edward Jaffe wrote:
Mark Hammack wrote:
I use the ADATA to aid in debugging with XDC (thanks
Dave!!!). There is a LOT of information in the ADATA including
'inline data' from macros, program labels, DSECT labels, comments,
etc. By using the ADATA I can get by without (in most cases)
having to have the listing available.
Full source-level debugging is an excellent feature I use whenever I
can. But, loading ADATA for large programs into z/XDC is a
relatively slow process that sometimes results in virtual storage
exhaustion for the address space being debugged.
ADATA is unwieldy. It consumes a lot of disk space. For example, a
single (E)JES build requires 54,000 tracks just for the ADATA file.
Why? There is a lot of redundancy in ADATA. For example, a common
mapping DSECT referenced in every compiled program is enumerated in
the ADATA output member for each of those programs. I know of no way
to suppress this behavior.
IBM's IDF developers did something right in this area. They wrote a
utility called ASMLANGX to extract the ADATA information required
for debugging in IDF. This extract file requires only a fraction of
the space occupied by full ADATA. Toolkit users that don't need
ADATA for anything else (e.g., the ASMPUT utility) can discard it
altogether. ASMLANGX members load quickly and put relatively little
pressure on virtual storage in the address space being debugged.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[email protected]
http://www.phoenixsoftware.com/
