| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Get/Put Rates on Two Mainframe Queues Appear Understated |
« View previous topic :: View next topic » |
| Author |
Message
|
| alanca53 |
 Posted: Wed Sep 18, 2013 11:21 am Post subject: MQ Get/Put Rates on Two Mainframe Queues Appear Understated |
 |
|
Newbie
Joined: 18 Sep 2013
Posts: 3
|
Hello All,
An MQ mystery I am actively researching. Would appreciate any insight as to what may be causing the behaviour I am observing. Running MQ V701 on the mainframe and MQ V6.0 on this particular distributed AIX.
Observed Issues:
Issue #1: MQ GET/PUT rates/counts reported by third party MQ monitor
and by MQ Explorer "Watch Activity" function are much lower for two
mainframe local queues than rates observed on related distributed
local queues. In this particular application, the number of messages
should be consistent across platforms.
Issue #2: The request messages on the distributed side and the response
messages on the mainframe side are missing information in their Put Date
/Time, User Identifier and Put Application Name fields.
Recap of Message Flow:
MF CICS tran #1 PUTs message to MF request Q1. Note that the Q1
message has valid info in Put Date/Time, User ID and Put Appl.
MF CICS tran #1 does EXEC CICS START on CICS tran #2, then terminates.
MF Started Task GETs message from MF Q1, adds some data to it and then
"forwards" (i.e. PUTs), the message to distributed request Q2. The
Q2 message "does not" have valid info in Put Date/Time, User ID
and Put appl. We don't have source code for the started task program.
Distributed process GETs message from Q2, processes it and then PUTs
response message to MF Q3. The Q3 message "does not" have
valid info in Put Date/Time, User ID and Put appl.
MF CICS tran #2 GETs message from response Q3 and uses it to complete
overall application processing flow that began with CICS tran #1.
The counts being displayed for Q1 and Q3 (i.e. mainframe queues),
are much lower than those seen on the distributed Q2.
The counts displayed for the Xmit queues going in both directions are in
line with those seen on the distributed Q2.
The application group reports that their distributed database counts are
in line with message counts seen on the distributed Q2.
The application appears to be processing normally. Noone is complaining
about anything being missing.
On a single message test run yesterday, I observed via the TSO MQ Admin
panels that Q1 showed a date/time for "LAST PUT" but had blanks for
date/time of "LAST GET". However, that test message did in fact make the
loop over to the distributed Q2 and then a response came back to the
mainframe Q3.
Very weird.
Thanks in advance for comments/feedback/suggestions.
Regards,
Alan Carter |
|
| Back to top |
|
 |
| JosephGramig |
| Posted: Wed Sep 18, 2013 11:50 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Alan,
When you don't see expected fields in the MQMD like UserID, Date, AppName, that means the application doing the PUT did it with 'setall' and didn't set those fields. Some server applications can have a valid reason to need to 'setall' but normally it would be 'passall' or 'passid'. Of course, I'm describing this in distributed terms.
Bottom line, when you see applications that do this, they were clearly developed by unqualified folks.
You should be concerned about this applications access. How was it vetted? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 18, 2013 12:21 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
More likely, the putting app specified MQPMO_NO_CONTEXT, which suppresses all context field information. If so, the PutApplType field in the MQMD should be set to MQAT_NO_CONTEXT.
_________________
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 |
|
|
| alanca53 |
| Posted: Wed Sep 18, 2013 12:53 pm Post subject: |
|
|
Newbie
Joined: 18 Sep 2013
Posts: 3
|
Hi Joseph,
Access start to finish on this particular message flow is tightly controlled. It originates from a trusted source which is thoroughly vetted prior to arriving to us and starting a CICS transaction.
We don't have access to source code for the program running as a started task so we can't really "see" what it is doing. However, from a user functionality perspective, it is working fine. From a systems perspective, some header fields are being left blank.
Continuing to poke around.
Regards,
Alan |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 18, 2013 12:54 pm Post subject: Re: MQ Get/Put Rates on Two Mainframe Queues Appear Understa |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| markt |
| Posted: Thu Sep 19, 2013 12:49 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
re #1
The "watch activity" plugin uses RESET QSTATS. If other monitoring tools are also using RESET QSTATS on the same queues at the same time, then they interfere with each other. |
|
| Back to top |
|
|
| alanca53 |
| Posted: Fri Sep 20, 2013 8:22 am Post subject: |
|
|
Newbie
Joined: 18 Sep 2013
Posts: 3
|
Peter,
The post you referred me to appears to be a perfect hit on my issue #1.
Check'em out:
http://www.mqseries.net/phpBB2/viewtopic.php?t=39415&start=0&postdays=0&postorder=asc&highlight=performance+feature
The original PUT to MF Q1 is for a non-persistent message and specifies MQPO-NO-SYNCPOINT. A mainframe started task then is continuously pulling messages from MF Q1.
Regarding my issue #2, this now appears to be a bug in the started task program that GETs messages from MF Q1. It is a vendor supplied object only program so I can't really tell exactly what it is doing (or not doing).
My original concern was that I erroneously had thought that I was getting blank data fields in only one of the two unique message flows that use this started task code. In retrospect, I now realize that the fields are blank in both message flows.
I appreciate everyone taking the time to read and respond to my post.
Regards,
Alan Carter |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
