ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Triggering problem...

Post new topic  Reply to topic Goto page Previous  1, 2
 Triggering problem... « View previous topic :: View next topic » 
Author Message
hughson
PostPosted: Thu Jun 22, 2017 9:59 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

cgache wrote:
The consuming application is tibco bw and connects via bindings (through a svr-conn) so no client conn channels being used.

Sorry to tell you, but if you are using a SVRCONN channel then there is a client conn channel at the other end

How that client conn channel is configured may be the problem, but in order to set a larger MAXMSGL on it, you will need to discover how it is configured. How does this consuming application indicate it's channel name, connection name and port, and so on? That's where you need to look for your missing MAXMSGL I suspect.

cgache wrote:
I'm not sure about buffer size maximums, could quite possibly come into play here as I'm almost certain the maxmsgl parameters have been adjusted all the way through.. still can't figure out why it ended up on the dlq with 2079

If this is using JMS, or some other Tibco provided wrapper, then those wrapper layers do put messages to the DLQ. Think BOTHRESH as mentioned earlier. But other reasons could also end up on the DLQ.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
cgache
PostPosted: Sun Jun 25, 2017 5:26 pm    Post subject: Reply with quote

Apprentice

Joined: 27 May 2013
Posts: 28
Location: Sydney, AUS

hughson wrote:
cgache wrote:
The consuming application is tibco bw and connects via bindings (through a svr-conn) so no client conn channels being used.

Sorry to tell you, but if you are using a SVRCONN channel then there is a client conn channel at the other end

How that client conn channel is configured may be the problem, but in order to set a larger MAXMSGL on it, you will need to discover how it is configured. How does this consuming application indicate it's channel name, connection name and port, and so on? That's where you need to look for your missing MAXMSGL I suspect.

cgache wrote:
I'm not sure about buffer size maximums, could quite possibly come into play here as I'm almost certain the maxmsgl parameters have been adjusted all the way through.. still can't figure out why it ended up on the dlq with 2079

If this is using JMS, or some other Tibco provided wrapper, then those wrapper layers do put messages to the DLQ. Think BOTHRESH as mentioned earlier. But other reasons could also end up on the DLQ.

Cheers,
Morag



Sorry let me rephrase.. tibco connects via a svr-conn, and I can't seem to see a client conn channel anywhere related to it..

as mentioned all the info to connect to the queue manager is via a bindings file as they are both on the same server.. i can't seem to find anything related to MAXMSGL in the bindings file.. maybe I'm looking in the wrong place.
Back to top
View user's profile Send private message
hughson
PostPosted: Sun Jun 25, 2017 7:37 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

cgache wrote:
Sorry let me rephrase.. tibco connects via a svr-conn, and I can't seem to see a client conn channel anywhere related to it..

as mentioned all the info to connect to the queue manager is via a bindings file as they are both on the same server.. i can't seem to find anything related to MAXMSGL in the bindings file.. maybe I'm looking in the wrong place.

If they are on the same machine is it possible for the app to connect locally instead of over the SVRCONN? Even if just temporarily this would allow you to determine whether the 2079 is as a result of some app buffer size Config or due to a CLNTCONN MAXMSGL that hasn't been increased (by removing the latter temporarily from the equation).

Then at least you'll KNOW what to track down.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Mon Jun 26, 2017 4:37 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

cgache wrote:

Sorry let me rephrase.. tibco connects via a svr-conn, and I can't seem to see a client conn channel anywhere related to it..

as mentioned all the info to connect to the queue manager is via a bindings file as they are both on the same server.. i can't seem to find anything related to MAXMSGL in the bindings file.. maybe I'm looking in the wrong place.


If Tibco connects through a SVRCONN there is forcibly a CLNTCONN at the other end. If the client conn has not been defined specifically that means you get the implicit CLNTCONN and that is limited to 4MB. If you want to expand the message size you need to either specify it in the program's (Tibco) connection parameters, or create a CLNTCONN, set the max message size on it and use a CCDT to connect to the queue manager using the defined CLNTCONN channel.

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
gbaddeley
PostPosted: Mon Jun 26, 2017 5:01 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

The Tibco MQ client adapter may not actually have a MQCD CLNTCONN structure inside it. All it is required to do is implement the MQ Client protocol over TCP/IP, to the satisfaction of the queue manager that is hosting the SVRCONN.
_________________
Glenn
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » General IBM MQ Support » Triggering problem...
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.