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 » 1300 character Message not transmitted

Post new topic  Reply to topic Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
 1300 character Message not transmitted « View previous topic :: View next topic » 
Author Message
flsb
PostPosted: Wed Oct 16, 2019 1:10 am    Post subject: Reply with quote

Apprentice

Joined: 01 Apr 2010
Posts: 41

HubertKleinmanns wrote:

When you split the message:

- Which size did these spitted messages have?
- Did it work when they where sent within one batch (e. g. 130 b and BATCHSZ 100)?
- Could you sent the bulk of splitted messages again and deliver the output of the following command before and after the transfer:
Code:
dis chs(<your Sender channel>) all


Some further questions:

- Does 'xxx' stand for an IP address or a host name?
- What's about the log size at your parties side? The content of "qm.ini" of your parties would be helpful.
- What's about the load on the parties side?

In Addition: I don't think, that DNS use used on a runnung channel. I assume, the DNS resolution only occurs when the channel starts.


ya.. 1.3k is not really large.. but it is 1300 characters long.. im suspecting the length not the size of it.. but there is no param on message length, only on message size..

well, it worked in my older AIX MQ v5.3.. only stopped working after we have migrated to RHEL MQ 9.1.

here is the sender channel status
AMQ8417I: Display Channel Status details.
CHANNEL(xxx.CHANNEL) CHLTYPE(SVR)
BATCHES(706) BATCHSZ(1)
BUFSRCVD(993) BUFSSENT(993)
BYTSRCVD(28044) BYTSSENT(855449)
CHSTADA(2019-10-15) CHSTATI(16.47.36)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(xxx(1414)) CURLUWID(5F37A35DC35F6E10)
CURMSGS(0) CURRENT
CURSEQNO(2388) EXITTIME(0,0)
HBINT(300) INDOUBT(NO)
JOBNAME(0000A50A00000001) LOCLADDR(xxx(44674))
LONGRTS(999999999) LSTLUWID(5F37A35DC25F6E10)
LSTMSGDA(2019-10-16) LSTMSGTI(17.05.55)
LSTSEQNO(2388) MCASTAT(RUNNING)
MONCHL(OFF) MSGS(706)
NETTIME(0,0) NPMSPEED(FAST)
RQMNAME(qmgrxxx) SHORTRTS(10)
SECPROT(NONE) SSLCERTI( )
SSLKEYDA( ) SSLKEYTI( )
SSLPEER( ) SSLRKEYS(0)
STATUS(RUNNING) STOPREQ(NO)
SUBSTATE(MQGET) XBATCHSZ(0,0)
XMITQ(xxx.TRAN.QUEUE) XQTIME(0,0)
RVERSION(08000004) RPRODUCT(MQMM)

the XXX in conname is the IP address, not hostname.

the log size should be default at receiver's end.
we are sending only plaintext in all our messages to the parties.. the load should be low..
Back to top
View user's profile Send private message
hughson
PostPosted: Wed Oct 16, 2019 1:13 am    Post subject: Reply with quote

Padawan

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

flsb wrote:
ya.. 1.3k is not really large.. but it is 1300 characters long.. im suspecting the length not the size of it.. but there is no param on message length, only on message size..

Isn't message length the same thing as message size? Please explain what the difference is in this context?

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
HubertKleinmanns
PostPosted: Wed Oct 16, 2019 3:32 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

flsb wrote:
ya.. 1.3k is not really large.. but it is 1300 characters long.. im suspecting the length not the size of it.. but there is no param on message length, only on message size..

The value of BYTSSENT is 855449 and the value of MSGS is 706. This means, your average message size is: 855449 / 706 = 1211.68... about 1.3 k .

flsb wrote:
well, it worked in my older AIX MQ v5.3.. only stopped working after we have migrated to RHEL MQ 9.1.

Should not be the difference .

flsb wrote:
the XXX in conname is the IP address, not hostname.

So it doesn't look like a DNS issue.

flsb wrote:
the log size should be default at receiver's end.

Normally these are the log defaults:
Code:
LogDefaults:
   LogPrimaryFiles=3
   LogSecondaryFiles=2
   LogFilePages=4096

This means the primary log size is: 3 * 4069 * 4k = 49152 k = 48 M

If you would send 50 messages per batch (default) with 1.3 k you would need a log space of: 50 * 1.3k = 65 k - so the log would be sufficient for these messages.

These are the minimum values (on Windows, on Linux LogFilePages is at least 64):
Code:
LogDefaults:
   LogPrimaryFiles=1
   LogSecondaryFiles=1
   LogFilePages=32

This means the minimum primary log size would be: 32 * 4k = 128 k - still enough for your messages.

flsb wrote:
the load should be low..

Then I would expect no big messages on the side of the parties, which could fill the log.

You wrote, that only two parties have this problem and the others run fine. So I assume, there is somthing different on the side of the parties.

You also wrote, the log size should be default and the load should be low. Could you please verify this?

And in addition, could you please verify the values of MAXMSGL for QMgr channel and queue at the side of the parties?

Do they have an exit in place?
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
HubertKleinmanns
PostPosted: Wed Oct 16, 2019 3:38 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

hughson wrote:
flsb wrote:
ya.. 1.3k is not really large.. but it is 1300 characters long.. im suspecting the length not the size of it.. but there is no param on message length, only on message size..

Isn't message length the same thing as message size? Please explain what the difference is in this context?

Cheers,
Morag


Hmm, what's about two-byte character sets?

And what's about sending a 1300 character text as XML file?

I'm not pretty sure what "1300 characters Long" really means.

I would say:

- message length: No. of characters
- message size: No. of bytes

But according to the channel statistics - in this case - "message length" and "message size" seems to be the same.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Wed Oct 16, 2019 7:18 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

HubertKleinmanns wrote:
Hmm, what's about two-byte character sets?

"Character" is from legacy mainframe days when a byte was exactly equal to a character. There was/is a chart that depicts the hex byte 00-FF and the character that the hex represented. A x'40' is/was a blank character, for example. See Appendix I EBCDIC and Other Codes in z/Architecture Principles of Operation https://www-01.ibm.com/support/docview.wss?aid=1&uid=isg26480faec85f44e2385256d5200627dee

Decades later IBM implemented double-byte character set (DBCS) to accommodate a broader range of iconic/graphical characters.

MaxMsgLength is defined at the queue/qmgr/channel in bytes.
_________________
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
View user's profile Send private message
gbaddeley
PostPosted: Wed Oct 16, 2019 3:55 pm    Post subject: Reply with quote

Jedi

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

flsb wrote:
it is just plain text..
total 1300 characters...
default MAXMSGL is 4Mb... i don't think the message can exceed 4Mb even with headers and encryption etc..
we have tried increasing to 10mb on Qmgr, channel and queue level.. and still fail to send..
The batchsz for both channel is set to 50... we tried to set as 1 but still failed to send..

Message lengths and batch sizes are irrelevant. They might be contributing to the frequency of the issue, but it is not root cause. Can we move on please.
_________________
Glenn
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Oct 16, 2019 4:44 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

What channel pair type? SVR-RCVR? or SVR-RQSTR?

What starts the channel?

Please display and post the receiving end channel definition. Display and post channel-status at the receiving end.
_________________
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
View user's profile Send private message
flsb
PostPosted: Wed Oct 16, 2019 6:16 pm    Post subject: Reply with quote

Apprentice

Joined: 01 Apr 2010
Posts: 41

What channel pair type?

SVR-RCVR and we even tried SDR-RCVR


Receiving end should be the default definition settings:

CHANNEL(xxx) CHLTYPE(RCVR)
ALTDATE(2019-10-01) ALTTIME(11.48.49)
BATCHSZ(50) CERTLABL( )
COMPHDR(NONE) COMPMSG(NONE)
DESCR( ) HBINT(300)
KAINT(AUTO) MAXMSGL(4194304)
MCAUSER( ) MONCHL(QMGR)
MRDATA( ) MREXIT( )
MRRTY(10) MRTMR(1000)
MSGDATA( ) MSGEXIT( )
NPMSPEED(FAST) PUTAUT(DEF)
RCVDATA( ) RCVEXIT( )
RESETSEQ(NO) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SEQWRAP(999999999)
SSLCAUTH(REQUIRED) SSLCIPH( )
SSLPEER( ) STATCHL(QMGR)
TRPTYPE(TCP) USEDLQ(YES)
Back to top
View user's profile Send private message
flsb
PostPosted: Wed Oct 16, 2019 6:24 pm    Post subject: Reply with quote

Apprentice

Joined: 01 Apr 2010
Posts: 41

HubertKleinmanns wrote:


You wrote, that only two parties have this problem and the others run fine. So I assume, there is somthing different on the side of the parties.

You also wrote, the log size should be default and the load should be low. Could you please verify this?

And in addition, could you please verify the values of MAXMSGL for QMgr channel and queue at the side of the parties?

Do they have an exit in place?


1 thing I noticed from these 2 parties are that they do NAT on their network to the MQ server.
Example,
A -> B (conname 192.168.0.1) -> NAT 192.168.0.1 to B local IP
B -> A (conname 20.20.20.1) -> NAT 20.20.20.1 to A destination IP -> A

Other parties will point to A destination IP in the conname to A
And A will point to B NAT ip and then to B local IP

But in these 2 parties, messages with shorter message length can go through in other channels

==========

No exit in place at both end and the MAXMSGL is the default value..
we have tried changing to 10Mb but still couldnt transmit through..
Back to top
View user's profile Send private message
flsb
PostPosted: Wed Oct 16, 2019 6:27 pm    Post subject: Reply with quote

Apprentice

Joined: 01 Apr 2010
Posts: 41

gbaddeley wrote:

Message lengths and batch sizes are irrelevant. They might be contributing to the frequency of the issue, but it is not root cause. Can we move on please.



i know it looks like it is pointing to a network problem instead of an MQ problem but a few factors are contradicting with one another..

1) other shorted messages can go through via other channels
2) the affected channel message can send through after splitting the message to shorted message and alter batchsz to 1
3) Wireshark and firewall logs show packets sent through

The only changes from this is upgrading from AIX MQ5.3 (physical server) to RHEL MQ 9.1 (VM)

And this happened before in one of my other MQ server version 7.5 as well and that we have to route the channel to AIXMQ5.3 to go through.
Back to top
View user's profile Send private message
hughson
PostPosted: Wed Oct 16, 2019 7:01 pm    Post subject: Reply with quote

Padawan

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

flsb wrote:
The only changes from this is upgrading from AIX MQ5.3 (physical server) to RHEL MQ 9.1 (VM)


I find the word "only" used in this sentence rather amusing. You have presumably changed hardware, physcial vs virtual machine, O/S type (and therefore O/S level), MQ level, and also firewall settings, network settings, and goodness knows what else.

Perhaps another way to ask this is, what haven't you changed?

My previous post on this thread suggested this is likely to be a firewall issue - have you looked into that further?

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
flsb
PostPosted: Wed Oct 16, 2019 7:51 pm    Post subject: Reply with quote

Apprentice

Joined: 01 Apr 2010
Posts: 41

hughson wrote:
flsb wrote:
The only changes from this is upgrading from AIX MQ5.3 (physical server) to RHEL MQ 9.1 (VM)


I find the word "only" used in this sentence rather amusing. You have presumably changed hardware, physcial vs virtual machine, O/S type (and therefore O/S level), MQ level, and also firewall settings, network settings, and goodness knows what else.

Perhaps another way to ask this is, what haven't you changed?

My previous post on this thread suggested this is likely to be a firewall issue - have you looked into that further?

Cheers,
Morag


i think the quote from AIX MQv5.3 (physical) to RHEL MQv9.1(vm) pretty much covers the changed in hardware, physical to VM, OS and MQ level.

On firewall side, we only change the object from the physical IP address to the VM ip address as we are changing the IP address to go out.

That is why i am pointing out the only changes done for this.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Oct 16, 2019 8:29 pm    Post subject: Reply with quote

Grand High Poobah

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

flsb wrote:
hughson wrote:
flsb wrote:
The only changes from this is upgrading from AIX MQ5.3 (physical server) to RHEL MQ 9.1 (VM)


I find the word "only" used in this sentence rather amusing. You have presumably changed hardware, physcial vs virtual machine, O/S type (and therefore O/S level), MQ level, and also firewall settings, network settings, and goodness knows what else.

Perhaps another way to ask this is, what haven't you changed?

My previous post on this thread suggested this is likely to be a firewall issue - have you looked into that further?

Cheers,
Morag


i think the quote from AIX MQv5.3 (physical) to RHEL MQv9.1(vm) pretty much covers the changed in hardware, physical to VM, OS and MQ level.

On firewall side, we only change the object from the physical IP address to the VM ip address as we are changing the IP address to go out.

That is why i am pointing out the only changes done for this.

If you haven't already done it, make sure the firewall has been opened for the correct zone at the linux/RHEL level.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
hughson
PostPosted: Wed Oct 16, 2019 9:14 pm    Post subject: Reply with quote

Padawan

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

flsb wrote:
On firewall side, we only change the object from the physical IP address to the VM ip address as we are changing the IP address to go out.

So how have you ensured that the firewall is the same in these two completely different environments?
_________________
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
flsb
PostPosted: Thu Oct 17, 2019 12:09 am    Post subject: Reply with quote

Apprentice

Joined: 01 Apr 2010
Posts: 41

hughson wrote:
flsb wrote:
On firewall side, we only change the object from the physical IP address to the VM ip address as we are changing the IP address to go out.

So how have you ensured that the firewall is the same in these two completely different environments?


as i've mentioned earlier..
the firewall only change on the object
example,

object MQserver from IP 192.168.0.1 (AIX MQ) to 192.168.0.2 (new RHEL MQ)

all firewall rules remain intact..
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, 3, 4, 5, 6, 7  Next Page 2 of 7

MQSeries.net Forum Index » General IBM MQ Support » 1300 character Message not transmitted
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.