| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| last api timestamp connection parameter |
« View previous topic :: View next topic » |
| Author |
Message
|
| jcv |
 Posted: Wed Feb 11, 2015 2:00 am Post subject: last api timestamp connection parameter |
 |
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Hello,
I would like to know what output parameter of "display connection" command gives the timestamp of the last api issued using that connection, if such parameter exists. UOWST and UOWLOG date and time seem to be the best candidates for such a consideration, to find out how busy or idle certain connection is, at least as far as I can see. Although, I'm not quite sure about that, because if an application operates outside of sync point control, these attributes probably don't give any information about that. Am I wrong?
For client connections I have other clues, in channel status, but actually I'm intersted in server connections. |
|
| Back to top |
|
 |
| MQsysprog |
| Posted: Wed Feb 11, 2015 2:57 am Post subject: |
|
|
Centurion
Joined: 24 Feb 2014
Posts: 116
|
Hello
I agree with your opinon on the informations available from the display connection command.
However, you could ask the accounting and stastics to the qmanager
in order to have a good amount of details on the resources , their status
and workload |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Feb 11, 2015 3:38 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| Yeah, well, connection seems to be the most natural placeholder for such an information. If you want an information at a glance about what's going on with certain connection, where would you wanna collect that information from rather than simply display that connection? But thanks for your opinion. |
|
| Back to top |
|
|
| MQsysprog |
| Posted: Wed Feb 11, 2015 4:27 am Post subject: |
|
|
Centurion
Joined: 24 Feb 2014
Posts: 116
|
Hi ,
yes well said again ,probably a monitor solution by a vendor could address
the request of a pinpoint observation of the resources and their state and behaviour ,but if we go in the past history of mq, we see a good amount of information features added on with the new versions ,so this area is for sure
a big field of Rfes to Ibm .
My thanks also for the good tought exchange ... |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed Feb 11, 2015 7:03 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| If you are MQ 7.1 or higher, another tool that could be helpful here is the Application Activity Trace. You could turn it on for 5 minutes and see what API activity the application is doing, by connection. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 11, 2015 8:12 am Post subject: Re: last api timestamp connection parameter |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| jcv wrote: |
Hello,
I would like to know what output parameter of "display connection" command gives the timestamp of the last api issued using that connection, if such parameter exists. |
Is your objective to identify inactive or hung or looping applications? Something else?
_________________
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 |
|
|
| jcv |
| Posted: Thu Feb 12, 2015 4:27 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| Something like that. Tim, this is exactly the opposite use case of monitoring mq resources, for which turning on trace for 5 minutes wouldn't help at all, if I want to find out if certain connection was busy at all, during let's say last 2 days. That's why I will propose RFE because I think that it wouldn't cost much to update connection with such an information about its activity. In terms of perfomance penalty, or development effort. UOW timestamps are about the current transaction, hence when not set at a certain moment, it doesn't mean there wasn't a commit performed a few moments ago. So they really don't give the same type of information that I'm interested in, they are good to spot a long running transaction. |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Feb 12, 2015 5:19 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| Ok, that makes sense. For historical application connection information on distributed platforms, accounting statistics would give you that information. But I also understand the desire of being able to find out that information, without having accounting statistics turned on. |
|
| Back to top |
|
|
| jcv |
| Posted: Thu Feb 12, 2015 10:04 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Hi again Tim, I see you deal a lot with mq tracing. Let me tell you that I modified a bit amqsactz.c for my own needs, and prepared a git repository on github.com being willing to share that with the community, and then decided to delete it since I didn't feel like asking around for permissions in order not to violate someone's intellectual property. And it wasn't a big deal, I merged it with amqscnxc.c in order to be able to connect to remote qmgrs, besides conname and svrconn channel, I added another command line argument, namely the traced queue name, in order to be able to filter out all unwanted AAT records, instead of printing out just
| Code: |
| printf("%02X", pMessageData[i] & 0xff); |
I added
| Code: |
| printf("%c", pMessageData[i]); |
(improved human readability easily), I added the option to print out only the records with MessageDataFindCd == 'Y'. That's about all, but to me very useful enhancement, since the main problem with mq API tracing (both AAT and strmqtrc) is a poor selectivity. Which of course isn't solved by this, but at least you can drain continuously (-w switch) S.A.T.A.Q on the busy qmgr and produce a compact and readable output. Of course, after you do all possible to exclude unwanted applications to produce messages there, it's still bad since AAT still puts messages there unnecessarily.
In the meantime, I noticed that there are already ibm-messaging and ibmmq github accounts and that Mark Taylor created some repositories there for similar purposes, so if he creates new one for amqsact0.c, and you contribute there, maybe I will too.
Cheers. |
|
| Back to top |
|
|
| jcv |
| Posted: Thu Feb 12, 2015 10:10 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| ... another option that I use from time to time is a -i Pid.Tid switch for strmqtrc, mainly when I want to trace channels. |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Feb 12, 2015 10:21 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Hi jcv,
I am glad you were able to get some use out of amqsactz. I have no concerns with you taking it and then posting your own changes for others to use. I posted it on the Capitalware web site so others could use it or change it, as needed.
Regards,
Tim |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Feb 12, 2015 7:55 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| jcv wrote: |
| ... another option that I use from time to time is a -i Pid.Tid switch for strmqtrc, mainly when I want to trace channels. |
I use strmqtrc a lot as well for problem determination, code reviews, resolving issues with my own code, etc.
I was curious, have you used the MH06 Trace Tools supportpac (specifically mqtrcfrmt) for helping with reading the API data structures? It also translates the trace data fields into a way were you can build a 5-10 line summary trace for each API call (which is documented in the supportpac) and improve on the selectivity of pulling data out of the trace. |
|
| Back to top |
|
|
| jcv |
| Posted: Fri Feb 13, 2015 2:11 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| There is a big difference between selectivity of pulling data out of the trace and of producing the selective trace. Which is what is meant when recent RFEs for strmqtrc and AAT were proposed. For example, for strmqtrc, only -p and -i switches address that need, on which I was so focused to that extent that when I spotted the -i Pid.Tid switch, I even considered the ability to use the information about Pids and Tids from, for example, queue usage type(handle) or connection type(handle) views, and write a program that would accept queue/channel name as input and start adequate trace. But that leads nowhere since that approach has issues. One of them being volatility, if queue handle isn't present, there is no pid.tid to look for at a certain moment to start the trace on. Which is not a problem for example when using -p switch which captures all handles done by that particular program during the whole period of trace, regardless of when they appear. So I discarded that idea and invested some time in amqsactz.c, and now I'm almost satisfied with the result. |
|
| Back to top |
|
|
| jcv |
| Posted: Fri Jul 10, 2015 6:06 am Post subject: Why is good they introduced DISCINT with SVRCONN chl type |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
So, when I said I have other clues for client connections, I meant LSTMSGDA and LSTMSGTI in channel status table.
| Code: |
$ echo "dis chl(SVRCONN_NAME) SHARECNV" | runmqsc QM_NAME
5724-H72 (C) Copyright IBM Corp. 1994, 2009. ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM_NAME.
1 : dis chl(SVRCONN_NAME) SHARECNV
AMQ8414: Display Channel details.
CHANNEL(SVRCONN_NAME) CHLTYPE(SVRCONN)
SHARECNV(10)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.
$ echo "dis chs(SVRCONN_NAME)" | runmqsc QM_NAME | grep AMQ8417 | wc -l
35
$ echo "dis chs(SVRCONN_NAME) LSTMSGDA" | runmqsc QM_NAME | grep LSTMSGDA
1 : dis chs(SVRCONN_NAME) LSTMSGDA
LSTMSGDA(2015-07-09) STATUS(RUNNING)
LSTMSGDA(2015-06-30) STATUS(RUNNING)
LSTMSGDA(2015-07-02) STATUS(RUNNING)
LSTMSGDA(2015-07-09) STATUS(RUNNING)
LSTMSGDA(2015-07-02) STATUS(RUNNING)
LSTMSGDA(2015-06-18) STATUS(RUNNING)
LSTMSGDA(2015-07-07) STATUS(RUNNING)
LSTMSGDA(2015-07-09) STATUS(RUNNING)
LSTMSGDA(2015-07-09) STATUS(RUNNING)
LSTMSGDA(2015-06-29) STATUS(RUNNING)
LSTMSGDA(2015-07-06) STATUS(RUNNING)
LSTMSGDA(2015-06-30) STATUS(RUNNING)
LSTMSGDA(2015-07-03) STATUS(RUNNING)
LSTMSGDA(2015-07-02) STATUS(RUNNING)
LSTMSGDA(2015-07-09) STATUS(RUNNING)
LSTMSGDA(2015-07-02) STATUS(RUNNING)
LSTMSGDA(2015-07-08) STATUS(RUNNING)
LSTMSGDA(2015-07-06) STATUS(RUNNING)
LSTMSGDA(2015-07-09) STATUS(RUNNING)
LSTMSGDA(2015-07-07) STATUS(RUNNING)
LSTMSGDA(2015-07-09) STATUS(RUNNING)
LSTMSGDA(2015-06-09) STATUS(RUNNING)
LSTMSGDA(2015-07-09) STATUS(RUNNING)
LSTMSGDA(2015-07-08) STATUS(RUNNING)
LSTMSGDA(2015-07-09) STATUS(RUNNING)
LSTMSGDA(2015-06-10) STATUS(RUNNING)
LSTMSGDA(2015-06-12) STATUS(RUNNING)
LSTMSGDA(2015-07-09) STATUS(RUNNING)
LSTMSGDA(2015-06-15) STATUS(RUNNING)
LSTMSGDA(2015-06-17) STATUS(RUNNING)
LSTMSGDA(2015-07-09) STATUS(RUNNING)
LSTMSGDA(2015-06-22) STATUS(RUNNING)
LSTMSGDA(2015-06-23) STATUS(RUNNING)
LSTMSGDA(2015-06-26) STATUS(RUNNING)
LSTMSGDA(2015-06-30) STATUS(RUNNING)
$ echo "dis conn(*) where (channel eq 'SVRCONN_NAME')" | runmqsc QM_NAME | grep AMQ8276 | wc -l
324
$ echo "dis conn(*) pid tid where (channel eq 'SVRCONN_NAME')" | runmqsc QM_NAME | grep PID | sort -u |wc -l
35
$ echo "dis chs(SVRCONN_NAME) CURSHCNV" | runmqsc QM_NAME | grep CURSHCNV
1 : dis chs(SVRCONN_NAME) CURSHCNV
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(9)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(1)
CURSHCNV(1)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(9)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(9)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(7)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(8)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
CURSHCNV(10)
$
|
So, there is a default of 10 connections per instance of SVRCONN_NAME channel, and in its 35 instances there are 324 connections contained, which you can count by summing CURSHCNV values of each instance. Also, you can count that there are exactly 35 unique PID TID pairs in these 324 connections. So far, so good. The problem is that some of them have LSTMSGDA older than 1 month. So, if there was no DISCINT (or ClientIdle pre-v7.1) ability, how would you handle those that are idle, with stop conn or stop chl commands? First, there is no switch for stop chl command that narrows the scope to only those instances whose LSTMSGDA is less than ..., and with respect to stop conn, there is no easy way to find out which of them are contained in a certain instance. One way would be by matching their PIDs and TIDs, but channel status table doesn't hold that info. So, that's why it is good they introduced it. Right? |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Jul 10, 2015 6:20 am Post subject: Re: Why is good they introduced DISCINT with SVRCONN chl typ |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| jcv wrote: |
| One way would be by matching their PIDs and TIDs, but channel status table doesn't hold that info. |
The PID/TID is in the DIS CHSTATUS in the JOBNAME attribute, but in hex.
So the following:
CHANNEL(MYSRVR.TO.YOURSRVR) CHLTYPE(SVRCONN)
JOBNAME(0000595300000611)
is using pid x'5953' = 22867 and tid x'611' = 1553
easy peasy, lemon squeezy, right? 
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
