| Author |
Message
|
| shashivarungupta |
 Posted: Mon Aug 03, 2009 2:36 am Post subject: CCDT and its client connection enteries !! |
 |
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
Hi All,
We have a system where some of the apps. used to connect to the queue managers using CCDT.
To connect to the mainframe Preproduction and Production they are using CCDT and in both the environments there are ServerConnectionChannel with the same name (obviously queue managers are diff.).
So, it was being noticed that when creating one CCDT for those Client connection channels referring to predefined server connection channels of diff. queue managers, there was only one entry for the client connection channel in CCDT instead of two (one for preprod. and another for production).
Is it true that only one entry would be there in CCDT, of the channels with the same name though those were defined on different queue managers?
[ Mostly I noticed that the last entry overwrites the previous ones when we are creating one CCDT for those multiple client channel definitions at diff. queue managers. ]
If this is true, then another question would be 'Why So' ?
Please suggest.
Appreciate that.
Thanks.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
 |
| exerk |
| Posted: Mon Aug 03, 2009 2:51 am Post subject: Re: CCDT and its client connection enteries !! |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| shashivarungupta wrote: |
...Mostly I noticed that the last entry overwrites the previous ones when we are creating one CCDT for those multiple client channel definitions at diff. queue managers...
...If this is true, then another question would be 'Why So' ?... |
Try defining two objects of the same name, and you'll have your answer...simple logic.
_________________
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 |
|
|
| shashivarungupta |
| Posted: Mon Aug 03, 2009 3:13 am Post subject: Re: CCDT and its client connection enteries !! |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| exerk wrote: |
| shashivarungupta wrote: |
...Mostly I noticed that the last entry overwrites the previous ones when we are creating one CCDT for those multiple client channel definitions at diff. queue managers...
...If this is true, then another question would be 'Why So' ?... |
Try defining two objects of the same name, and you'll have your answer...simple logic. |
I got what you mean to say...
We can't have two objects of the same name as two members in a family with the same name would create confusion to the other family members itself. (specifically, 2 objects of the same name as channel/queue on the same queue manager.)
But then when we have those objects with same name but on diff. queue managers then name conflict should not be there. (in that case internal reference should work that means check the family to which that member belongs to.)
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Aug 03, 2009 3:19 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Exactly. Maintain a Pre-Production level queue manager CCDT, and a Production-level CCDT, preferably by using different queue managers to create/maintain them, or qualify the names by adding an environmental identifier to the channel name.
_________________
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 |
|
|
| shashivarungupta |
| Posted: Mon Aug 03, 2009 3:46 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| exerk wrote: |
| Exactly. Maintain a Pre-Production level queue manager CCDT, and a Production-level CCDT, preferably by using different queue managers to create/maintain them, or qualify the names by adding an environmental identifier to the channel name. |
| Quote: |
| ...qualify the names by adding an environmental identifier to the channel name. |
I did that to avoid the name conflict and created one CCDT. and that worked.
But you know.. application teams are demanding always... to avoid there side changes they asked to have one CCDT for different environments ( means prepod. , production, development, test etc.) and where we had channels with same name. 
so problem appeared there.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 03, 2009 4:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If the teams are using CCDTs, then they don't care what the name of the *channel* is.
The channel is chosen from the CCDT based on the name of the *queue manager*. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Aug 03, 2009 4:35 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
I missed that in the original post! 
Note to self - read to end-of-line
_________________
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 |
|
|
| shashivarungupta |
| Posted: Mon Aug 03, 2009 4:50 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| mqjeff wrote: |
If the teams are using CCDTs, then they don't care what the name of the *channel* is.
The channel is chosen from the CCDT based on the name of the *queue manager*. |
..if thats the fact then "why I got that CCDT with one definition of the channel, even though the channels were on different queue managers but with the same name" ? (as I said earlier that definition was the last one which replaced earlier definitions in that CCDT.)
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 03, 2009 6:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The channels have to have different names to be in the same CCDT.
But the app doesn't care what the name of the channel is.
It's going to do an MQCONN and specify the queue manager name. That is going to used to find a channel in the CCDT that has that value configured.
The app is never going to use nor know the channel name.
If the app is specifying a channel name, then they are not using a CCDT properly. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Mon Aug 03, 2009 6:37 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| mqjeff wrote: |
The channels have to have different names to be in the same CCDT.
But the app doesn't care what the name of the channel is.
It's going to do an MQCONN and specify the queue manager name. That is going to used to find a channel in the CCDT that has that value configured.
The app is never going to use nor know the channel name.
If the app is specifying a channel name, then they are not using a CCDT properly. |
| Quote: |
...if the teams are using CCDTs, then they don't care what the name of the *channel* is.
...The channels have to have different names to be in the same CCDT. |
Got the point on which you, exerk and myself are agreed upon. NO DUPLICATION or NO NAME CONFLICT in one CCDT.
(as i said earlier, "...when we have those objects with same name but on diff. queue managers then name conflict should not be there. (in that case internal reference should work that means check the family to which that member belongs to." )
That proves your and my point, both.
But if the application teams are not concerned about the *channels* name but the *queue manager* names...then how and why does it matter, that *channel* names are same or different.
Anyways I got the answers.
Thanks.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Aug 03, 2009 4:24 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| exerk wrote: |
| Exactly. Maintain a Pre-Production level queue manager CCDT, and a Production-level CCDT, preferably by using different queue managers to create/maintain them, or qualify the names by adding an environmental identifier to the channel name. |
A common best practise is to have one CCDT that propagates through all environments (dev, test, uat, preprod, prod etc) with the application deployment. Assuming every env will have a unique qmgr name, the CLNTCONN channel names in the CCDT are also made unique. eg.
MYAPP.QMTST1.CLIENT connects to QMTST1
MYAPP.QMUAT1.CLIENT connects to QMUAT1
MYAPP.QMPRD1.CLIENT connects to QMPRD1
All the app then needs to do is connect to the appropriate qmgr for that environment.
_________________
Glenn |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Aug 03, 2009 11:37 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| gbaddeley wrote: |
| exerk wrote: |
| Exactly. Maintain a Pre-Production level queue manager CCDT, and a Production-level CCDT, preferably by using different queue managers to create/maintain them, or qualify the names by adding an environmental identifier to the channel name. |
A common best practise is to have one CCDT that propagates through all environments (dev, test, uat, preprod, prod etc) with the application deployment. Assuming every env will have a unique qmgr name, the CLNTCONN channel names in the CCDT are also made unique. eg.
MYAPP.QMTST1.CLIENT connects to QMTST1
MYAPP.QMUAT1.CLIENT connects to QMUAT1
MYAPP.QMPRD1.CLIENT connects to QMPRD1
All the app then needs to do is connect to the appropriate qmgr for that environment. |
_________________
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 |
|
|
| gbaddeley |
| Posted: Tue Aug 04, 2009 3:26 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| exerk wrote: |
| gbaddeley wrote: |
| exerk wrote: |
| Exactly. Maintain a Pre-Production level queue manager CCDT, and a Production-level CCDT, preferably by using different queue managers to create/maintain them, or qualify the names by adding an environmental identifier to the channel name. |
A common best practise is to have one CCDT that propagates through all environments (dev, test, uat, preprod, prod etc) with the application deployment. Assuming every env will have a unique qmgr name, the CLNTCONN channel names in the CCDT are also made unique. eg.
MYAPP.QMTST1.CLIENT connects to QMTST1
MYAPP.QMUAT1.CLIENT connects to QMUAT1
MYAPP.QMPRD1.CLIENT connects to QMPRD1
All the app then needs to do is connect to the appropriate qmgr for that environment. |
|
Yes exerk, I was giving examples of adding an environmental identifier, namely the application and the qmgr, and the technique of using one CCDT for all environments (in contrast to your example, which also works).
_________________
Glenn |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Aug 04, 2009 9:23 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Horses for courses...one is easier to maintain, but I have had to maintain multiple due to the requirement to ensure separation of environments - no internal 'firewalls' in between, and on at least one occasion a Production-level app was connected to a lower-environment queue manager; the wrong app ini file was deployed.
_________________
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 |
|
|
| shashivarungupta |
| Posted: Wed Aug 05, 2009 1:54 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
exerk
| Quote: |
| ..I have had to maintain multiple due to the requirement to ensure separation of environments |
True, it happens.
In our situation neither application teams want to make their code changes nor the infrastructure layer where we fall.
It happens when changes have to be done to minimize the major chaos in the system, after receiving nods from all. 
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
|
|
