| Author |
Message
|
| zkarj |
 Posted: Wed Jul 02, 2014 8:09 pm Post subject: Monitoring server connection channels |
 |
|
Newbie
Joined: 02 Jul 2014
Posts: 5
|
Having spent a considerable time building a program to process MQ event messages (channel and queue depth messages are of interest to me) I am now left with one significant gap. Server Connection channels.
Such channels:
1. Do not generate events.
2. Can not be enquired on by API (no channels can).
3. Do not display at all in a DIS CHSTATUS(*) if not RUNNING (because they fall back to INACTIVE and no INACTIVE channels are displayed).
We have applications that use MQ Client to connect to our IBM i MQ server installation and (in production) they should be connected 24x7. I want to catch a dropping of these channels and send an alert.
Unless I'm missing something, the only way to programatically watch server connection channels is through MQSC commands and a lot of fluffing about:
DIS CHANNEL(*) TYPE(SVRCONN)
Parse that to get the channel names
DIS CHSTATUS(xxx) for each found in the above parsing
Parse each of those to look for RUNNING status or an AMQ8420: Channel Status not found.
What am I missing? Is this ugly, cumbersome approach the only way? If so, I may have to find a *nix guru to build a grep/sed/awk stack to 'simplify'. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Jul 02, 2014 8:51 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20729
Location: LI,NY
|
Have you thought about trying to do that through PCF messages?? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zkarj |
| Posted: Wed Jul 02, 2014 9:09 pm Post subject: |
|
|
Newbie
Joined: 02 Jul 2014
Posts: 5
|
| fjb_saper wrote: |
| Have you thought about trying to do that through PCF messages?? |
I hadn't, thanks.
It looks like the same problems with status will exist. It does at least shift the emphasis off parsing wodges of text but would still require enumerating all definitions before attempting to get a status for each.
When I saw the description of this particular forum as for the "odd ball" platforms I let out a wry laugh. MQ is the oddball in my experience! "When is a status not a status? When it's in MQ!"
Actually the other approach I had looked at but couldn't figure out (thanks to IBM's stellar documentation) is the WHERE clause on a DIS CHSTATUS. Anyone know where I can find examples of the actual keywords I can use there? I'm guessing it won't help me but it would be useful to find more than the cryptic paragraph IBM provide on the topic. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 03, 2014 9:45 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20729
Location: LI,NY
|
Provide those as arguments to the pcf call.
One trick (to avoid enumeration) would be to retrieve one hand all svrconn channels and on the other hand all svrconn channel statuses.
If status not present, but existing svrconn ==> the channel is idle...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zkarj |
| Posted: Sun Jul 20, 2014 8:00 pm Post subject: |
|
|
Newbie
Joined: 02 Jul 2014
Posts: 5
|
So this kept bugging me and I eventually figured I had to skin the cat*.
Rather than write a ton of gnarly code to parse the output I used my limited *nix knowledge and a lot of Googling and a LOT of trial and error and came up with this beauty.
echo "dis channel(*) type(svrconn)"
| /QSYS.LIB/QMQM.LIB/RUNMQSC.PGM
| egrep 'CHANNEL\('
| sed -e 's/CHANNEL(/dis chstatus(/' -e 's/CHLTYPE(SVRCONN)//'
| /QSYS.LIB/QMQM.LIB/RUNMQSC.PGM
| sed -e 's/AMQ8420.*$/STATUS(INACTIVE)/' -e 's/^.*dis chstatus[(]\(.*\)[)]/CHNL(\1)/'
| egrep 'CHNL[(]|STATUS[(]'
| uniq
| paste -d' ' - -
| sed 's/ */ /g'
> svrconnsts.txt
This is for IBM i, hence the ugly QSYS.LIB stuff, but that could be replaced with a simple runmqsc command on other platforms I believe. On IBM run the above as a QShell command (yes, double up all those single quotes!) and of course choose a relevant path/file at the end.
I still need to parse the final result to generate my alerts, but when it looks like this that task is a LOT simpler.
CHNL(AJ.SRVCONN) STATUS(INACTIVE)
CHNL(IA112.CLT.RISLST) STATUS(INACTIVE)
CHNL(IA112.CLT.RISLSTAGE) STATUS(INACTIVE)
CHNL(IA112.CLT.RISLTEST1) STATUS(RUNNING) SUBSTATE(RECEIVE)
CHNL(IA112.CLT.RISLTEST2) STATUS(INACTIVE)
CHNL(IA112.CLT.RISLTEST3) STATUS(INACTIVE)
CHNL(IA112.CLT.RISLTEST4) STATUS(INACTIVE)
CHNL(IA112.UTIL.SVRCN) STATUS(INACTIVE)
CHNL(SYSTEM.AUTO.SVRCONN) STATUS(INACTIVE)
CHNL(SYSTEM.DEF.SVRCONN) STATUS(INACTIVE)
Chances are it could be simplified a bit because I built all that up s-l-o-w-l-y, piece by piece as I came to grips with syntax and regex. but it works.
*For anyone whose first language is not English, this phrase may need explaining. See here. |
|
| Back to top |
|
|
| IanAlderson |
| Posted: Mon Jul 21, 2014 2:03 am Post subject: |
|
|
Novice
Joined: 23 Apr 2014
Posts: 17
|
Glad you have got something working there. I would just like to throw out some thoughts for you to consider. Hopefully one or more items may be useful for you.
SVRCONN channels are, as I'm sure you realise, effectively MQI connections from applications, and in that respect they are fundamentally different from say monitoring a SDR / RCVR channel. So I think when application connections are critical it is more normal to monitor the open connections on a queue (IPPROCS) and alert on that per queue.
If you do decide to stick with monitoring the SVRCONN channel, what is the consequence if you have say 10 application connections on a single channel, but one of them is down? How would you alert on that? Also note that with shared connections, an application may make more than one connection on a single channel instance (represented as a single running channel status).
So considering the above, if it is more helpful to monitor the number of connections (let us say there are 10 expected), then you could check the connections that match a channel name and then do a word count to compare.
Here is an example unix-style (as I don't even want to attempt an AS400 version  )
| Code: |
| echo dis conn(*) where (channel eq AJ.SVRCONN) | runmqsc MyQMgr | grep AMQ8276 | wc -l |
If you are also interesting in the queue name and want to do something with that take a look at TYPE(HANDLE) on the display conn. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 21, 2014 5:01 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20729
Location: LI,NY
|
And as I said before, pcf would allow you to make this query platform independant...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| IanAlderson |
| Posted: Mon Jul 21, 2014 6:00 am Post subject: |
|
|
Novice
Joined: 23 Apr 2014
Posts: 17
|
| fjb_saper wrote: |
| And as I said before, pcf would allow you to make this query platform independant... |
Whilst that is true up to a point - if you're writing it in java - it is not a trivial thing to write a pcf program. It is up to the OP to decide what is the most appropriate choice for his requirements and his and his team's skillset to maintain. Certainly if you were buying a commercial package then you would expect it to be using pcf but that doesn't mean it's always the most appropriate choice for homegrown monitoring.
However regardless of the method used the point I am making is whether there is any value in monitoring the status of a SVRCONN channel.
| fjb_saper wrote: |
One trick (to avoid enumeration) would be to retrieve one hand all svrconn channels and on the other hand all svrconn channel statuses.
If status not present, but existing svrconn ==> the channel is idle... |
Unless you have a situation where each instance of an application has its own unique SVRCONN definition then that approach is not going to alert you to when an application instance is down whilst other apps are connected to that channel. The correct approach in my opinion is to either monitor the open counts on the queues or the connections that are tied to a channel. |
|
| Back to top |
|
|
| zkarj |
| Posted: Mon Jul 21, 2014 1:46 pm Post subject: |
|
|
Newbie
Joined: 02 Jul 2014
Posts: 5
|
Thanks for the thoughts.
The SVRCONN channels are indeed unique per application. They are created/treated pretty much like a dedicated SDR/RCVR channel, so the channel should be operational (almost) 24x7 and if not, the remote app isn't running and it should be.
I'm actually mystified why they chose to go the client route instead of running a queue manager on their local server. Especially given the reason I was told - "We're worried the system will be down a lot and may lose messages." Yeah, I felt like finding the brochure for MQ and pointing out what it actually is.
My team's role is purely at the platform level and we can't rely on the app team on either side to know or care about any of this, so we do the best we can. Similarly, if we catch a SVRCONN channel INACTIVE there's nothing we can do about it other than alert the other team, but as they don't seem to be monitoring their end, we may as well at least do that.
My next challenge is to figure out how to turn state monitoring into events, but at least that problem is outside of the MQ domain. |
|
| Back to top |
|
|
| zkarj |
| Posted: Mon Jul 28, 2014 9:06 pm Post subject: |
|
|
Newbie
Joined: 02 Jul 2014
Posts: 5
|
I hit a wrinkle in my almost complete solution.
I suddenly realised this QShell command...
| Code: |
| echo "dis channel(*) type(svrconn)" | /QSYS.LIB/QMQM.LIB/RUNMQSC.PGM > /temp/mqout.txt |
...was running on the default and not on a named queue manager.
A quick tinker later yielded the (perhaps obvious?) solution.
| Code: |
| echo "dis channel(*) type(svrconn)" | /QSYS.LIB/QMQM.LIB/RUNMQSC.PGM 'named.queue.manager' > /temp/mqout.txt |
Just thought I'd post in case anyone else uses this. |
|
| Back to top |
|
|
|
|
