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 » Perl script to Move messages between queues & retain con

Post new topic  Reply to topic Goto page Previous  1, 2
 Perl script to Move messages between queues & retain con « View previous topic :: View next topic » 
Author Message
fjb_saper
PostPosted: Wed Feb 03, 2016 5:50 am    Post subject: Reply with quote

Grand High Poobah

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

Again your MQGET has a dangerous option:
Code:
MQGET Successful using MQGMO_FAIL_IF_QUIESCING | MQGMO_ACCEPT_TRUNCATED_MSG | MQGMO_BROWSE_NEXT

Please remove MQGMO_ACCEPT_TRUNCATED_MSG and handle the error by increasing the buffer accordingly...

How would you like for your application to have only a fragment of the original message, if you do have to resend / reprocess that message?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
LouML
PostPosted: Wed Feb 03, 2016 6:21 am    Post subject: Reply with quote

Partisan

Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY

fjb_saper wrote:
Again your MQGET has a dangerous option:
Code:
MQGET Successful using MQGMO_FAIL_IF_QUIESCING | MQGMO_ACCEPT_TRUNCATED_MSG | MQGMO_BROWSE_NEXT

Please remove MQGMO_ACCEPT_TRUNCATED_MSG and handle the error by increasing the buffer accordingly...

How would you like for your application to have only a fragment of the original message, if you do have to resend / reprocess that message?


I have BufferLength set to 4MB on the MQGET call, which is much larger than any message we deal with. It seems unlikely that this will occur. However, your objection is noted.

Maybe I'll make it an optional runtime flag, to allow or disallow truncated msgs.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude
Back to top
View user's profile Send private message
mqjeff
PostPosted: Wed Feb 03, 2016 6:35 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

MQ will always return a buffer that holds the entire message (unless accept truncated messages), and it won't pad this to the size of the passed in buffer.

So if 4MB is significantly larger than your message size, you'll never get a full 4MB buffer.

And if you use accept truncated messages on some other queue, where the messages are much larger - how will your user know that the message that was copied/moved is now smaller than the original?
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
LouML
PostPosted: Thu Feb 04, 2016 5:26 am    Post subject: Reply with quote

Partisan

Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY

mqjeff wrote:
MQ will always return a buffer that holds the entire message (unless accept truncated messages), and it won't pad this to the size of the passed in buffer.

So if 4MB is significantly larger than your message size, you'll never get a full 4MB buffer.

And if you use accept truncated messages on some other queue, where the messages are much larger - how will your user know that the message that was copied/moved is now smaller than the original?


Let me start off by saying I've removed the MQGMO_ACCEPT_TRUNCATED_MSG option so I can focus on the context issue.
In hindsight, I should not have used it since (IMHO) I don’t believe I ever would have received a truncated message.

However, this was my rationale for using MQGMO_ACCEPT_TRUNCATED_MSG.

-The queue definitions in our firm are the same between Prod and DR. So if a queue has a MAX length of 4194304 in Prod, it has it in DR.
-4MB is larger by far than any message on any queue in our firm .
-To me, if a message was successfully Put to the Source queue by an application, it should make it to the Target queue without any issues.

So, If I set BufferLength (input) to 4MB, it should accommodate any message I could possibly receive

If any of my assumptions above were incorrect, then I suppose I’d have learned the hard way.

I must say, I truly do appreciate the opinions and insights from so many of the senior members of this forum. Even when opinions vary, it's nice to hear all sides.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude
Back to top
View user's profile Send private message
LouML
PostPosted: Thu Feb 04, 2016 5:40 am    Post subject: Reply with quote

Partisan

Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY

mqjeff wrote:
It's odd that adding the context would alter which mqconn you get. But there at least were some old restrictions on using more than one qmgr connection in a single thread - that you would always get the same handle back. This does match your situation, except for the part about working without context options.


I'm not sure I follow. I get the correct mqconn both ways. Did you get this from the output I posted? If so, I can see the confusion.

I basically test this by moving the messages back and forth between the two QM/Q's. So, to do this, I change the command line options (source values use 1 and Target options use 2).

This moves mesages from QMTEST1 to QMTEST2
Code:
[mqm@mqm3d ~]$ ./Queue2QueueNEW.pl -m1 QMTEST1 -q1 QL.DEV.TEST2 -x1 'NMS.SVRCONN/TCP/mqdev(1418)' -m2 QMTEST2 -q2 QL.DEV.TEST2 -x2 'NMS.SVRCONN/TCP/mqdev(1419)'
---------------------------- Move FROM  -----------------------------
MQ Queue Manager = QMTEST1
Queue Name       = QL.DEV.TEST2
MQSERVER         = NMS.SVRCONN/TCP/mqdev(1418)
Channel          = NMS.SVRCONN
Transport        = TCP
Hostname(port)   = mqdev(1418)
---------------------------- TO -------------------------------------
MQ Queue Manager = QMTEST2
Queue Name       = QL.DEV.TEST2
MQSERVER         = NMS.SVRCONN/TCP/mqdev(1419)
Channel          = NMS.SVRCONN
Transport        = TCP
Hostname(port)   = mqdev(1419)
---------------------------------------------------------------------
Connected to QMTEST1 (HConn1 = 16777222) at mqdev(1418) using channel NMS.SVRCONN
Connected to QMTEST2 (HConn2 = 16777224) at mqdev(1419) using channel NMS.SVRCONN
---------------------------------------------------------------------
[mqm@mqm3d ~]$


This moves mesages from QMTEST2 to QMTEST1
Code:
[mqm@mqm3d ~]$ ./Queue2QueueNEW.pl -m2 QMTEST1 -q2 QL.DEV.TEST2 -x2 'NMS.SVRCONN/TCP/mqdev(1418)' -m1 QMTEST2 -q1 QL.DEV.TEST2 -x1 'NMS.SVRCONN/TCP/mqdev(1419)'---------------------------- Copy FROM  -----------------------------
MQ Queue Manager = QMTEST2
Queue Name       = QL.DEV.TEST2
MQSERVER         = NMS.SVRCONN/TCP/mqdev(1419)
Channel          = NMS.SVRCONN
Transport        = TCP
Hostname(port)   = mqdev(1419)
---------------------------- TO -------------------------------------
MQ Queue Manager = QMTEST1
Queue Name       = QL.DEV.TEST2
MQSERVER         = NMS.SVRCONN/TCP/mqdev(1418)
Channel          = NMS.SVRCONN
Transport        = TCP
Hostname(port)   = mqdev(1418)
---------------------------------------------------------------------
Connected to QMTEST2 (HConn1 = 16777222) at mqdev(1419) using channel NMS.SVRCONN
Connected to QMTEST1 (HConn2 = 16777224) at mqdev(1418) using channel NMS.SVRCONN
---------------------------------------------------------------------
[mqm@mqm3d ~]$

_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude
Back to top
View user's profile Send private message
mqjeff
PostPosted: Thu Feb 04, 2016 5:49 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

LouML wrote:
mqjeff wrote:
It's odd that adding the context would alter which mqconn you get. But there at least were some old restrictions on using more than one qmgr connection in a single thread - that you would always get the same handle back. This does match your situation, except for the part about working without context options.


I'm not sure I follow. I get the correct mqconn both ways. Did you get this from the output I posted? If so, I can see the confusion.


No, sorry. I was responding to the bit where you said that using context options didn't work for MOVE. Or at least it looked like it didn't. And I had misunderstood the conditions that you said were relevant when this happened.

If that's not at all what you're talking about, then

_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu Feb 04, 2016 5:59 am    Post subject: Reply with quote

Grand High Poobah

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

So what you're saying is that when you're moving the messages between 2 qmgrs context option SAVEALL does not work for you?
Has the id / group been authorized for SAVEALL on the target object?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
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 » Perl script to Move messages between queues & retain con
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.