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
