Tracelog should include resource consumption count analysis

Improved tooling is required to benchmark resource consumption for a specific application path beyond mere clock or processing time. The Performance Analyzer breaks down time spent in various code modules and the number of calls made etc to identify hot spots in code components. Tracelog provides the ability to track an application path flow once an ECB has been trapped. However, neither tool includes a breakdown of resource consumption (including find/file activity, core usage, pool consumption) across the ECB life, never mind by code module. Lack of insight into system resource consumption (the what, where, and how many of core, file, pool) means we have no means of gaining insight into an absolutely essential part of effective application benchmarking, performance testing, and change analysis during application development and stages of testing.

ZTRAP EA allows runtime collection of flow for trapped ECBs and includes summaries of core and file usage but trapping the ECB you want is not always guaranteed, and certainly not always easy, and the summaries provided are for the ECB life. A much more rigiorous means of determining what an ECB consumes where is needed.

Enhancing tracelog or PA seems viable, but tracelog may be the more effective option given that this would allow a developer to trap the ECB they were interested and then benchmark its profile.

The additional information needed would ideally be available at the code component (source file) level, but at a minimum must be availalble at the SO level, and ECB lifetime level. The resources that need to be tracked are, at a minimum:
1) core usage (core blocks, ecb heap, system heap)
2) 4K consumption due to COW
3) find/file activity, including IDs involved
4) GRFS activity, including IDs where applicable
Additional stats on tape usage and create activity might also be useful.