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 » IBM MQ API Support » C# to IBM MQ-Remove the MQHRF2 from the requests

Post new topic  Reply to topic Goto page 1, 2, 3  Next
 C# to IBM MQ-Remove the MQHRF2 from the requests « View previous topic :: View next topic » 
Author Message
sathyapbe
PostPosted: Mon Apr 16, 2018 8:18 am    Post subject: C# to IBM MQ-Remove the MQHRF2 from the requests Reply with quote

Novice

Joined: 16 Apr 2018
Posts: 21

Hi,

I am new to C# to IBM web sphere MQ integration. The very first request to MQ doesn't have the additional headers but the subsequent requests has the additional headers. We are using external MQ so we don't have any control to change the option there. Any one of you can please help me to get rid of the additional headers from the subsequent requests.

amqmdnet.dll version 8.0.0.4

Thanks in advance!
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Apr 16, 2018 9:45 am    Post subject: Re: C# to IBM MQ-Remove the MQHRF2 from the requests Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

sathyapbe wrote:
We are using external MQ so we don't have any control to change the option there.


External to your application? External to your organization?

sathyapbe wrote:
Any one of you can please help me to get rid of the additional headers from the subsequent requests.


Have you posted this in the Message Broker section because there's a message broker somewhere in your topology, because you think MB & MQ are the same product or because you didn't read the section headings before posting? It's important because MB uses RFH2 for some functions.

Why do you need to remove them? Why not just ignore them if they contain no information that you need? What problem are they causing?
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
sathyapbe
PostPosted: Mon Apr 16, 2018 10:01 am    Post subject: Reply with quote

Novice

Joined: 16 Apr 2018
Posts: 21

Thanks for the reply!

External to my application.

Sorry for the confusion. My query is related to MQ.

Due to this additional headers the end host service is not processing the requests so the transactions are getting failed. I have to send the requests without additional headers. Please let me know if you want more details.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Apr 16, 2018 10:35 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

sathyapbe wrote:
External to my application.


So you could request on-site admins to change queue manager and/or queue properties if required.

sathyapbe wrote:
Due to this additional headers the end host service is not processing the requests so the transactions are getting failed. I have to send the requests without additional headers.


If you were using JMS, you'd use a property called TARGCLIENT to indicate the receiver wasn't JMS and the extra JMS properties (the contents of the RFH2) should not be transmitted. As you're using XMS I've no idea what the equivalent is; a C# developer will be along in a minute I'm sure.

In the meantime, look for a method on the queue object you're using in your code to put the message that talks about target type, message type or something of that nature. Experiment with various values, especially anything that calls itself "Native", "MQ", IBM MQ" or "Not JMS".
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Apr 16, 2018 10:36 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

sathyapbe wrote:
Sorry for the confusion. My query is related to MQ.


Moving to more relevant section.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
sathyapbe
PostPosted: Mon Apr 16, 2018 10:50 am    Post subject: Reply with quote

Novice

Joined: 16 Apr 2018
Posts: 21

I have been searching the similar property JMS TARGCLIENT in C# from the day1 but no luck.

One mystery is happening the same C# .NET client build is sending requests without additional headers from one windows server but from another similar windows server requests has the additional headers.

Checked the windows servers OS, IIS and configurations. It seems all are similar.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Apr 16, 2018 10:57 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

sathyapbe wrote:
One mystery is happening the same C# .NET client build is sending requests without additional headers from one windows server but from another similar windows server requests has the additional headers.

Checked the windows servers OS, IIS and configurations. It seems all are similar.


Have the MQ admins checked that the queue managers in question have the same compatibility settings? One may be set to hold attributes as properties (modern behavior), one may be set to hold attributes as RFH2 headers (old behavior, retained even in MQv8 for backwards compatibility)
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Mon Apr 16, 2018 7:46 pm    Post subject: Reply with quote

Grand High Poobah

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

sathyapbe wrote:
I have been searching the similar property JMS TARGCLIENT in C# from the day1 but no luck.

One mystery is happening the same C# .NET client build is sending requests without additional headers from one windows server but from another similar windows server requests has the additional headers.

Checked the windows servers OS, IIS and configurations. It seems all are similar.

Look for the targetClient property on the Destination. It can also be set dynamically by the destination URI:
Code:
qname="queue:///MY.QUEUE?targetClient=1";
MQQueue = (MQQueue) session.createQueue(qname);

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
sathyapbe
PostPosted: Mon Apr 16, 2018 10:09 pm    Post subject: Reply with quote

Novice

Joined: 16 Apr 2018
Posts: 21

Vitor,

I think we almost reached the issue root cause. Thank you!
I have CAT windows server and PROD windows server with the similar configurations and the same C# API build. Both are sending the request to the same IBM MQ. CAT server requests doesn't have additional headers but PROD server subsequent requests has the additional headers.

While reach out to MQ admin, how can I ask the question to check the "set to hold attributes". In the queue manager, do we have settings for each client servers with server name?

fjb_saper,

I am getting the below error while changing the queue name as per your advise. Please correct me if I am wrong.

Error trying to open Request Queue for writing. Error[2085]

Code:

_requestQueueName = "queue:///XXX.REQUESTS?targetClient=1";
private MQQueue _requestQueue;

_requestQueue = _mqQMgr.AccessQueue(_requestQueueName,
MQC.MQOO_OUTPUT // open queue for output
+ MQC.MQOO_FAIL_IF_QUIESCING);
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Apr 17, 2018 2:31 am    Post subject: Reply with quote

Grand High Poobah

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

so you get 2085 error which means the queue does not exist on the queue manager you are connected to. Try "queue://QMGRNAME/QNAME?targetClient=1" or if cluster replace QMGRNAME with cluster alias name...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Tue Apr 17, 2018 5:17 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

sathyapbe wrote:
While reach out to MQ admin, how can I ask the question to check the "set to hold attributes". In the queue manager, do we have settings for each client servers with server name?


Both channels and queues have a PROPCTL attribute that controls the handling of an RFH2 header.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
sathyapbe
PostPosted: Tue Apr 17, 2018 6:28 am    Post subject: Reply with quote

Novice

Joined: 16 Apr 2018
Posts: 21

Vitor,

Both CAT and PROD servers are sending the requests to the same IBM MQ, same Queue Manager, channel, request queue and response queue but how come the attribute is varying for the different client.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Apr 17, 2018 7:06 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

sathyapbe wrote:
Both CAT and PROD servers are sending the requests to the same IBM MQ, same Queue Manager, channel, request queue and response queue but how come the attribute is varying for the different client.


Do CAT & PROD host queue managers, or are both servers hosting examples of this application clienting to a single queue manager?

If so, why are (what sounds like) Prod and non-Prod messages going to the same queue?

Explain your topology. Carefully.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
RogerLacroix
PostPosted: Tue Apr 17, 2018 9:16 am    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3252
Location: London, ON Canada

sathyapbe, ignore everything related to JMS as it is a red herring unless you are using XMS with C#.

Is the target (destination) queue in the SAME queue manager as that which you are connecting to?

i.e. If you C# .NET application is connecting to queue manager 'MQA1', is the target queue (i.e. 'ABC.Q') in MQA1 or does the message hope to another queue manager i.e. MQB1.

Topology:

C# .NET app ---> MQA1 with queue 'ABC.Q'

or is it

C# .NET app ---> MQA1 <---> MQB1 with queue 'ABC.Q'

i.e. Is there a XMIT involved?

You need to compare the PROPCTL of your target queue and XMIT (if one is used) between your CAT and PROD environments.

i.e. CAT
DIS Q(ABC.Q) PROPCTL
DIS Q(MQB1.XMIT) PROPCTL

i.e. PROD
DIS Q(ABC.Q) PROPCTL
DIS Q(MQB1.XMIT) PROPCTL

Most likely one of them is NOT set to 'COMPAT'.

Of course, this is assuming you are actually running the same code in both environments.

Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
sathyapbe
PostPosted: Tue Apr 17, 2018 9:21 am    Post subject: Reply with quote

Novice

Joined: 16 Apr 2018
Posts: 21

Due to lack of test accounts we haven't used CAT IBM MQ server.

While doing the testing we were using our windows CAT server and pointed to PROD IBM MQ. It was working as expected.

We rolled out the application to our windows PROD server and pointed to PROD IBM MQ. It is not working as expected because of the additional headers.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2, 3  Next Page 1 of 3

MQSeries.net Forum Index » IBM MQ API Support » C# to IBM MQ-Remove the MQHRF2 from the requests
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.