Eureka! If one digs deep enough (couple miles should do), RMF III will report what service class a DDF thread was classified into.
The reason I wanted this was because I had a strong suspicion one of my prod DDF workloads was still falling out of the ruleset to default (suspicion based on indirect evidence). Since the workload in question was coming in through VTAM (all threads through the same LU name), I changed the pertinent sub-rule to an LN type and they magically started classifying correctly. I was very curious why CI did not work for these threads. Using the new found RMF III info, I discovered that the CI was being sent by the AIX system in lower case*. Changed the sub-rule back to type CI and specified the name in lower case, taking care to specify "N" for "fold qualifier name" (they sure could have named that more intuitively). Now the threads classify correctly by CI. Thanks a bunch to all who replied! I learned more than I bargained for in this little adventure, but that's always (usually) a good thing. *TMON was reporting this CI in upper case for some reason. I will report that to the TMON/MVS folks. On Fri, 24 Mar 2006 08:26:00 +1000, Shane <[EMAIL PROTECTED]> wrote: >On Thu, 2006-03-23 at 12:04 -0600, Terry Linsley wrote: > >> Is there a straight forward method of determining if an enclave is >> dependant? Would an example of one be when a DB2 utility spawns multiple >> threads to build an index during a table load or recovery? > >RMFIII has an indicator - I think that's what twigged me to go find out >what the hell a dependent enclave was. >PP isn't any help. > >I'd be *REAL* surprised if any have surfaced in your environment unless >it was the home-grown stuff - ours was, although not Java. > >We had a small local batch job that did some DB2 log analysis - this is >where the dep enclave came from. Ops noticed it (apparently) wasn't >doing anything, and reset the job. >Still wasn't doing anything, but the shop stopped - no prod batch was >going anywhere. Eventually I got a call. The dependant enclave came >along for the ride, and was consuming a full engine - out of 3. >At 2.10, this was *very* hard to track down. >Ops got kicked (again) for using reset. > >Even these episodes aren't enough to cause a change of mind about >mandatory logon on the consoles. > >Shane ... > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
