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 IndexIBM MQ Installation/Configuration SupportWhen is defining a client connection on the server necessary

Post new topicReply to topic
When is defining a client connection on the server necessary View previous topic :: View next topic
Author Message
KL2017
PostPosted: Mon Sep 18, 2017 12:17 pm Post subject: When is defining a client connection on the server necessary Reply with quote

Newbie

Joined: 18 Sep 2017
Posts: 3

Hello,

We have 2 channels, both server-connections, between a Nonstop and a Window's server. The Nonstop is the server, the Window's machine is the client. These have been working, non-ssl channels and we've been struggling to switch them to SSL (but that's not my main question).

From the Nonstop, when I display Channel_A, I see information for both the server connection and the client connection.
When I display Channel_B, I only see information for the server connection.

Why is no client connection information defined for Channel_B? Or is it that the client connection information never needed to be defined for Channel_A? Or somewhere in the middle?

Like I mentioned, we've struggled to switch Channel_B to SSL and I wonder if the lack of client connection information on the server may have something to do with it.

Thanks.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Sep 18, 2017 12:21 pm Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24614
Location: Ohio, USA

To establish a client connection to a queue manager (and you establish a connection to the queue manager not the hosting server), you need a SVRCONN channel defined on the queue manager. Period.

Depending on a number of factors (including but not limited to the need to specify SSL parameters) you may need to define a CLNTCONN channel and supply it to the client, or you may not.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
KL2017
PostPosted: Mon Sep 18, 2017 12:28 pm Post subject: Reply with quote

Newbie

Joined: 18 Sep 2017
Posts: 3

Vitor wrote:
To establish a client connection to a queue manager (and you establish a connection to the queue manager not the hosting server), you need a SVRCONN channel defined on the queue manager. Period.

Depending on a number of factors (including but not limited to the need to specify SSL parameters) you may need to define a CLNTCONN channel and supply it to the client, or you may not.


Thanks Vitor. Would it be safe to say that these factors would come mostly from the client, i.e. the application running on the client using the channel to connect to the queue manager on the server?
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Sep 18, 2017 12:41 pm Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24614
Location: Ohio, USA

KL2017 wrote:
Vitor wrote:
To establish a client connection to a queue manager (and you establish a connection to the queue manager not the hosting server), you need a SVRCONN channel defined on the queue manager. Period.

Depending on a number of factors (including but not limited to the need to specify SSL parameters) you may need to define a CLNTCONN channel and supply it to the client, or you may not.


Thanks Vitor. Would it be safe to say that these factors would come mostly from the client, i.e. the application running on the client using the channel to connect to the queue manager on the server?


I would say no. I might be a bit old school but it's always been my view that MQ topology is the province of the MQ administrator who defines the topology. The application shouldn't know or care what it's connecting to and thus maintain the asynchronous, fully mobile application connectivity which is the hallmark of a message based model. So a client might be provided with a series of CLNTCONN details in the form of a CCDT where from an application functionality point of view it could make do with a SVRCONN, but there's wider HA considerations the administrator is taking care of.

This of course breaks down (to your point) if the application has specific requirements that can only be met through the use of a CLNTCONN/SVRCONN pairing. This still doesn't mean (and I would assert that it's best practice) that the application knows it's using a CLNTCONN or refers to it in the connection logic.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Sep 18, 2017 12:44 pm Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24614
Location: Ohio, USA

Other, more modern viewpoints are equally valid.

They're just wrong.


(The machine has been broken since 11am and I'm stuck listening to the most worthless conference call ever, unable to seek proper medical assistance in Starbucks.)
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
KL2017
PostPosted: Mon Sep 18, 2017 12:56 pm Post subject: Reply with quote

Newbie

Joined: 18 Sep 2017
Posts: 3

Vitor wrote:
Other, more modern viewpoints are equally valid.

They're just wrong.


(The machine has been broken since 11am and I'm stuck listening to the most worthless conference call ever, unable to seek proper medical assistance in Starbucks.)



Thanks Vitor
This is some excellent information; i'm still wrapping my head around some of these concepts but I have some solid knowledge to go off of now.
Back to top
View user's profile Send private message
JosephGramig
PostPosted: Tue Sep 19, 2017 10:25 am Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1180
Location: Derby City, USA

Furthermore, MQ V8 and up Client can create and manage CCDTs with the runmqsc command now. They "product-itized" the support pack that used to do that. The thing is, it will only work on the same version or later versions of the MQ Client.

What I mean is, a CCDT created with a specific version of MQ is only compatible with that version and up elsewhere.

I'm sure that wasn't perfectly clear and I hope you know what I meant to say...

I guess I too have not had enough coffee.
Back to top
View user's profile Send private message AIM Address
exerk
PostPosted: Tue Sep 19, 2017 11:29 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5749

JosephGramig wrote:
Furthermore, MQ V8 and up Client can create and manage CCDTs with the runmqsc command now. They "product-itized" the support pack that used to do that. The thing is, it will only work on the same version or later versions of the MQ Client.

What I mean is, a CCDT created with a specific version of MQ is only compatible with that version and up elsewhere.

I'm sure that wasn't perfectly clear and I hope you know what I meant to say...

I guess I too have not had enough coffee.

Not quite...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexIBM MQ Installation/Configuration SupportWhen is defining a client connection on the server necessary
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.