Author |
Message
|
KL2017 |
Posted: Mon Sep 18, 2017 12:17 pm Post subject: When is defining a client connection on the server necessary |
|
|
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 |
|
 |
Vitor |
Posted: Mon Sep 18, 2017 12:21 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, 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 |
|
 |
KL2017 |
Posted: Mon Sep 18, 2017 12:28 pm Post subject: |
|
|
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 |
|
 |
Vitor |
Posted: Mon Sep 18, 2017 12:41 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, 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 |
|
 |
Vitor |
Posted: Mon Sep 18, 2017 12:44 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, 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 |
|
 |
KL2017 |
Posted: Mon Sep 18, 2017 12:56 pm Post subject: |
|
|
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 |
|
 |
JosephGramig |
Posted: Tue Sep 19, 2017 10:25 am Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, 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 |
|
 |
exerk |
Posted: Tue Sep 19, 2017 11:29 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
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 |
|
 |
|