I think you are correct in your suspicion that the new policy is the cause. Changing the resource cap can't produce your problem, but maybe he or someone else made a change to the policy earlier, that was activated too at the moment the reportclass stopped logging. Possible causes in the policy are (obviously) remove of the reportclass, changed the reportclassname, or changed the order in the classification rules, such that they match another line. Ask the wlm guy to compare the current policy to the one active before the change, which has been backuped I assume.
Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hylton Tom P Sent: Thursday, July 25, 2013 17:11 To: IBM-MAIN@LISTSERV.UA.EDU Subject: WLM Report Class not cutting records 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 ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN