| Author |
Message
|
| tone |
 Posted: Mon Mar 03, 2003 7:03 pm Post subject: Monitoring Channel Activity |
 |
|
Newbie
Joined: 17 Mar 2002
Posts: 5
|
I was wondering if anyone know of a way to monitor the level of through put on a channel?
We are looking at protecting the mainframe from an excessive amount of messages from the Web application coming across the channel by monitoring the channel and then stopping the channel if it exceeds a certain limit.
Currently we are setting the maxQDepth on the mainframe queues to a reasonable level but this doesn't to appear to be enough when the mainframe is able to process the messages quick enough to not let the queue depth hit this mark.
I also, looked at the service interval on the queue but this seems more designed to raise an alert when the messages are sitting on the queue for too long.
If there are any other options that I haven't thought of it would be great to hear about them as well.
thanks
tony |
|
| Back to top |
|
 |
| kolban |
| Posted: Mon Mar 03, 2003 9:16 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Interesting ... I was going to talk about channel exits and message exits and all sorts of esoteric ideas ... instead, can you further clarify what it is that you want to happen?
Do you want to stop a channel (of messages arriving from somewhere else) when a mainframe queue reaches a certain depth and have it restarted when the level falls?
If this is not the correct understanding, can you run it past me again explaining what effect you want to achieve? |
|
| Back to top |
|
|
| tone |
| Posted: Mon Mar 03, 2003 9:39 pm Post subject: |
|
|
Newbie
Joined: 17 Mar 2002
Posts: 5
|
We are not 100% sure of our final position. I believe the best thing would be to stop the channel and have the situation reviewed by staff. This would protect us from a large amount of valid but unwanted processing that could occur in the case of a denial of service attack.
The other option that was raised is, as you say, to stop the channel and reopen it once the mainframe had caught up with the processing.
If you could give me ideas on both it would be much appreciated.
tony |
|
| Back to top |
|
|
| kolban |
| Posted: Tue Mar 04, 2003 7:07 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
When a queue reaches a pre-configured depth (not necessarily full) an MQSeries event message can be generated. This event message can be processed by an application either on the receiving side or the sender side of channels. The message indicates the hi-water mark of a queue has been reached. This can be an indication that the queue is too full and needs to have a channel stopped.
Through the use of PCF, channels can be stopped or started programatically (true for MQ products other than MVS ... not sure about MVS).
One could configue the hi-water mark on a queue and, when it reaches that value, switch of the channel such that no new messages arrive. |
|
| Back to top |
|
|
| Troilus |
| Posted: Tue Mar 04, 2003 7:24 am Post subject: |
|
|
Apprentice
Joined: 12 Jul 2002
Posts: 28
Location: Belgium
|
On MVS-OS/309-z/OS you can send a message to the command server to stop a channel too. But to keep live interesting you can not use the same PCF format.
Just looking at the transmission queue depth does not seem to be sufficient, as the original poster wants to cater for the situation where the number of bytes send per second is too high, but the sender can still cope.
Why not periodically do a dis chstatus and look at bytssent, make the difference with the previous measurement... et voila. |
|
| Back to top |
|
|
| kolban |
| Posted: Tue Mar 04, 2003 10:42 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
| That's why I reasked the question. Message depth is one factor, bytes transmitted is another. I am thinking that the byte count is a red-herring and the message depth (number of requests to process) is the key factor. |
|
| Back to top |
|
|
|
|
