| Author |
Message
|
| prKinch |
 Posted: Mon Feb 15, 2010 2:43 pm Post subject: Analysis the MQ logs |
 |
|
Novice
Joined: 31 Jan 2010
Posts: 15
|
I need ur  .......
We need to read the MQ**CHIN and find the channels which is in stopped state and time... And keep this details in the ps. We will run this job daily.
Please give me an idea about this |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Feb 15, 2010 2:52 pm Post subject: Re: Analysis the MQ logs |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| prKinch wrote: |
| We need to read the MQ**CHIN and find the channels which is in stopped state and time... And keep this details in the ps. We will run this job daily. |
I find it highly unlikely you need this. If your site is set up halfway correctly a channel shouldn't be in a stopped state without an alert and someone getting paged. Or having been paged a while previously when it didn't come out of retry within the expected period.
| prKinch wrote: |
| Please give me an idea about this |
If you actually want to review the CHIN logs there's nothing stopping you. If you want to review the SMF records there's a support pac for that.
But recording what time the channel stopped is like recording what time your house burnt down. It's useful, but a smoke alarm is more help.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 15, 2010 2:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Or does this tie back to this post and you're trying to figure out when the channel stopped because the sequence number was wrong?
If so, use the advice in the other thread. Stop trying to work out when the fire started and just put it out.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| prKinch |
| Posted: Mon Feb 15, 2010 5:06 pm Post subject: Reply |
|
|
Novice
Joined: 31 Jan 2010
Posts: 15
|
I need to get the details... Just sent the alert to support team,Incase the channel is ubnormally went down.
For that, I need to take the details from the background job "MRSTCHIN"
(JESMSG) log |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 15, 2010 5:19 pm Post subject: Re: Reply |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| prKinch wrote: |
For that, I need to take the details from the background job "MRSTCHIN"
(JESMSG) log |
- that's a potentially confusing name for it (given what the z/OS queue manager is typically called)
- as you've identified the name of the JES log why are you posting here?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Feb 15, 2010 5:53 pm Post subject: Re: Analysis the MQ logs |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| prKinch wrote: |
I need ur .......
We need to read the MQ**CHIN and find the channels which is in stopped state and time... And keep this details in the ps. We will run this job daily.
Please give me an idea about this |
Run CSQUTIL in a batch job to issue MQSC command "DISPLAY CHSTATUS(*) CURRENT". The output will indicate which channels are in STOPPED state.
_________________
Glenn |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 15, 2010 6:22 pm Post subject: Re: Analysis the MQ logs |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gbaddeley wrote: |
| Run CSQUTIL in a batch job to issue MQSC command "DISPLAY CHSTATUS(*) CURRENT". The output will indicate which channels are in STOPPED state. |
Would a stopped channel have a current state? It might well have a saved one.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 15, 2010 7:25 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
This wheel has already been invented.
The queue manager will create an event message when a channel stops. So, a more direct method might be to monitor the SYSTEM.ADMIN.CHANNEL.EVENT queue for those messages.
You could write an application program that gets triggered when a channel event message arrives.
Most mainframe shops have a variety of automation software watching for these and other events. Tivoli Netview and Tivoli Omegamon are two possibilities. What monitoring software does your shop have?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 15, 2010 7:32 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bruce2359 wrote: |
This wheel has already been invented.
The queue manager will create an event message when a channel stops. So, a more direct method might be to monitor the SYSTEM.ADMIN.CHANNEL.EVENT queue for those messages.
You could write an application program that gets triggered when a channel event message arrives.
Most mainframe shops have a variety of automation software watching for these and other events. Tivoli Netview and Tivoli Omegamon are two possibilities. What monitoring software does your shop have? |
Make sure if you go that route that you are able to differentiate between the stopped in inactive state and the stopped in stopped state. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 15, 2010 7:49 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...you are able to differentiate between the stopped in inactive state and the stopped in stopped state. |
Channel event messages are described in the WMQ Monitoring manual.
Reason code in MQCFH structure will have
MQRC_CHANNEL_STOPPED_BY_USER (2279, X’8E7’) Channel stopped by user when a user issues a STOP CHL command. Other ReasonCodes are described, too. In my v7 manual, this is on page 80. [edit for page number]
One of my clients (with POS terminals at the other ends of their channels) monitors the channel event queue for channels in retry, so they don't have to wait for the short- and long-retry intervals to finally expire before they are alerted.
[edit] With v7, channel events may be disabled/enabled (like other event), and may be limited to exceptional conditions, so no events will be generated for channel starts and regular channel stops.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Feb 16, 2010 2:10 pm Post subject: Re: Analysis the MQ logs |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Vitor wrote: |
| gbaddeley wrote: |
| Run CSQUTIL in a batch job to issue MQSC command "DISPLAY CHSTATUS(*) CURRENT". The output will indicate which channels are in STOPPED state. |
Would a stopped channel have a current state? It might well have a saved one. |
Yes it does.
| Code: |
1 : DIS CHS(*) CURRENT
AMQ8417: Display Channel Status details.
CHANNEL(MQGBT1.MQGBT2.T1) CHLTYPE(SDR)
CONNAME(127.0.0.1(1415)) CURRENT
RQMNAME( ) STATUS(STOPPED)
SUBSTATE( ) XMITQ(MQGBT2)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed. |
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 16, 2010 2:23 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
We need to read the MQ**CHIN and find the channels which is in stopped state and time... And keep this details in the ps. We will run this job daily.
Please give me an idea about this |
Aren't you interested in why your channel stopped? If you only collect this information daily, will the channel remain stopped until someone looks at the sysout from the batch job?
Are you trying to collect historical data about channel outages? Without knowing why the channel failed? If so, this is an odd requirement: I don't care why; I just want to know how many!
Perhaps you could explain with more precision what the business requirement is.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 16, 2010 2:44 pm Post subject: Re: Analysis the MQ logs |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gbaddeley wrote: |
| Vitor wrote: |
| gbaddeley wrote: |
| Run CSQUTIL in a batch job to issue MQSC command "DISPLAY CHSTATUS(*) CURRENT". The output will indicate which channels are in STOPPED state. |
Would a stopped channel have a current state? It might well have a saved one. |
Yes it does.
|
I am filled with new knowledge.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
