Provide option to specify jobs for which detailed thread data should be OMITTED from the QAPMJOBMI file

In a large system environment, where there are jobs that are known to generate millions of secondary threads per day, Collection Services becomes almost unusable due to the amount of data in the QAPMJOBMI file.

This request is to provide an option to specify a job name, where secondary thread data from that job is not populated into the QAPMJOBMI file.

The file already includes a count of the number of threads created and the number of active threads, so there is data in the file that can be used to understand threading characteristics without the detail data of every thread.

The Management Collection object can contain the full set of data; the request is simply to exclude the thread data from the file.

This support needs to be part of the configuration when creating the database files during each interval collection, as well as when doing a full create of the performance data from the management collection object.

The client has a single job that generates millions of secondary threads each day. Many of these are short-lived and the JBSLTCNT count is incremented.

However, there are a sufficient number of threads that live more than one second such that the QAPMJOBMI file is around 34GB for a 24 hour collection.

The current circumventions are to expand the short-lived thread lifetime beyond one second, and to cycle the collection every 4 hours.

While these circumventions are helpful, an option to completely omit this thread data from the QAPMJOBMI file for jobs that are known to create millions of secondary threads would make analysis of the performance data faster, as well as more useful.

Having the full set of data in the Management Collection Object would allow for the option to create the file data with all threads included if this is required for analysis.