I'm observing a curious situation that I'm trying to understand. Note: I'm not the wlm sysprog or even an SME by any means, I'm just using the data from a performance aspect, so I hope this description is clear enough to muddle through.
SERVICE_CLASS_1 = REPORT_CLASS_1, so no external stuff to gum up the example. If something runs under that service class, it gets reported in that report class. Everything was rolling along as expected until Monday. On Monday at 14:00, testing in that SC ended, so SERVICE_CLASS_1 = REPORT_CLASS_1 = 0 in the reporting periods following the testing halt (as expected). Both were still cutting records on 15 minute intervals even though they only contained zeros. On Monday at 15:25, the wlm guy activated a new policy. He swears the only change was to increase the resource cap of SERVICE_ CLASS_1. At the next reporting interval (15:30), SERVICE_CLASS_1 still has same behavior as prior to the change. It still cuts a record every 15 minutes, still containing zeros because no testing is occurring. However, the REPORT_CLASS_1 behavior has changed. There are no longer any records being cut for REPORT_CLASS_1 at all. Instead of a zero record, I get no record at all and haven't since 15:15 on Monday. WLM guy's theory is that when changes were activated, the "buckets" were emptied, and since there hasn't been any new activity since then, that there won't be any more records cut in REPORT_CLASS_1 until something actually comes in to that service class. I'm skeptical because there are still service class records being cut. I'm not knowledgeable enough to know whether the behavior should be the same or different for SC vs RC, whether it's a bug, or whether something botched up during the last policy change. And I can't seem to hit a meaningful search in the vile infocenter to find the correct manual to look at. If I can't find an explanation, I'm going to try to get a transaction executed to see if his theory is correct, but it's burdensome because this activity happens to be ddf transactions kicked off remotely on a different platform far far away. Thanks, tom ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
