| Author |
Message
|
| dextermbmq |
 Posted: Thu May 05, 2016 4:57 pm Post subject: Queue manager groups in the CCDT |
 |
|
Voyager
Joined: 26 Jul 2014
Posts: 77
|
Hello All,
I have been trying to implement the concept of QMGR Groups in CCDT.
(Got some good read content at :http://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q027490_.htm?lang=en)
SETUP
We have a qmgr : TEST1 running in Multi instance mode with Active Instance and Passive Instance on Linux servers-say Server1 and Server2
Also, there is a standalone queue manager TEST2 running on Linux Server say Server 3.
A local queue (say TEST_QL) is defined on TEST1 and TEST2 Queue Managers
REQUIREMENT
Now the requirement is :
1- App should connect to Active Instance of the Queue Manager TEST1 and should post messages to queue TEST_QL
2- In case the Active Instance fail overs to different server : Server2, the application should then connect to Server2 and post messages there
3-If both Active and Passive instances are unavailable , the app should then post the messages to the Queue Manager TEST2 on Server3.
To test it , I am using amqsphac utility. I have used Queue Manager groups concept in CCDT.
The channel definitions are created as :
For multi-instance
------------------------
DEFINE CHANNEL(A) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME('XXXX(3430),YYYY(3430)') QMNAME('QM') REPLACE
For Stand alone Queue Manager
--------------------------------------
DEFINE CHANNEL(A) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME('XXXX(3430)') QMNAME('QM') REPLACE
COMMAND USED FOR TESTING IS :
amqsphac TEST_QL *QM
ISSUE
when I am failing over the multiinstance Queue Manager, the amqsphac utility instead of connecting to Multi-Instance Queue Manager TEST1 on the new Active Node , connects to stand alone queue manager TEST2.
Thus , the amqsphac utility is not waiting for the failover to occur , rather its directly connecting the standalone queue manager.
Can anyone please assist on how can we make sure the amqsphac utility connects to the standalone queue manager TEST2 only when both the active and passive nodes of multi-instance queue managers are down
Thanks in advance..!! |
|
| Back to top |
|
 |
| PaulClarke |
| Posted: Thu May 05, 2016 9:16 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Why have you used the same channel name for both Queue Managers ? The MQ CCDT does not support this. The second DEFINE CHANNEL over-wrote your first DEFINE CHANNEL, If you change to use channel B for the Server3 Queue Manager then I suspect it will work.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| exerk |
| Posted: Fri May 06, 2016 1:18 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
|
| Back to top |
|
|
| dextermbmq |
| Posted: Mon May 09, 2016 6:48 pm Post subject: |
|
|
Voyager
Joined: 26 Jul 2014
Posts: 77
|
Hello Paul,
That was a typo. I had used different channel names (Channel Named A and Channel Named B to make sure names are in proper alphabetical order)
Hello Exerk,
Thanks for the helpful content.
To be precise I was trying to implement the Scenario 4 from the PDF. But as described below , the amqsphac utility is not waiting for the MQ failover to happen , rather the messages are directly getting delivered to the Queue Manager TEST2. I wanted a setup where messages reach TEST2 only when both active and passive nodes of multiinstance queue manager TEST1 are unavailable.
So, is it dependant on appplication logic ???.
I mean if we create an application where the reconnect attempt is made by the application after a gap of say 5 mins(assuming the MQ failover would not take more time than this) , we can achieve a scenario where the messages will reach the new Active Node once the previously Active Node fails over. Finally if both nodes are down the messages will reach the queue manager TEST2.
Regards
Dexter |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue May 10, 2016 1:16 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Hi,
I can't immediate think how you can automatically achieve this. If you are using client reconnect then you can choose whether the client has affinity (MQCNO_RECONNECT_Q_MGR) or doesn't (MQCNO_RECONNECT). I don't think you can say that you want a little bit of affinity - ie. reconnect to the same Queue Manager for a little while (say 5 minutes) and only if this fails connect somewhere else.
However, it was a long time ago since I wrote this code so I may have forgotten an option or two. You could, clearly, do it yourself in your own application logic by making the two different types of connection yourself.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| blorro |
| Posted: Mon Jul 11, 2016 11:52 pm Post subject: |
|
|
Acolyte
Joined: 09 Jan 2014
Posts: 57
Location: Sweden
|
Hijacking thread with a question related to the mentioned PDF and CCDT .
I am propably "doing it wrong" when testing out usage of CCDT file on a server with MQ Client installed (8.0.0.4).
i've tried using sample program "amqsputc" but keep getting "MQRC_Q_MGR_NAME_ERROR".
For testing connectivity with CCDT file with MQ Client , do i have to use "amqsphac" or are there other options ? |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue Jul 12, 2016 12:47 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
You can use AMQSPUTC and the CCDT - AMQSPHAC is for demonstrating client reconnect. Did you need to test reconnect ?
To analyse your MQRC_Q_MGR_NAME_ERROR I think we would need to see the contents of your CCDT and the parameters you are passing to AMQSPUTC.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| blorro |
| Posted: Tue Jul 12, 2016 12:59 am Post subject: |
|
|
Acolyte
Joined: 09 Jan 2014
Posts: 57
Location: Sweden
|
I've played around with different ones.
Do i need to restart the server on each change , ie. replacing AMQCLCHL.TAB for instance ?
this is the last one, where i used servernames on the two nodes where qmgrs are running:
| Code: |
AMQ8414: Display Channel details.
CHANNEL(CQMWDE.DMZ1) CHLTYPE(CLNTCONN) DESCR( ) TRPTYPE(TCP) CONNAME(servername1.domain.dom (1414))
QMNAME(QMDMZTST) LOCLADDR( ) USERID( ) PASSWORD( ) MODENAME( ) TPNAME( ) MAXMSGL(104857600)
HBINT(300) SCYEXIT( ) SCYDATA( ) SENDEXIT( ) SENDDATA( ) RCVEXIT( ) RCVDATA( )
COMPHDR(NONE) COMPMSG(NONE) SSLCIPH( ) SSLPEER( ) SHARECNV(10) CLNTWGHT(0) AFFINITY(PREFERRED)
DEFRECON(NO) ALTDATE(2016-07-11) ALTTIME(16.21.27)
AMQ8414: Display Channel details.
CHANNEL(CQMWDE.DMZ2) CHLTYPE(CLNTCONN) DESCR( ) TRPTYPE(TCP) CONNAME(servername2.domain.com(1415))
QMNAME(QMDMZTST) LOCLADDR( ) USERID( ) PASSWORD( ) MODENAME( ) TPNAME( ) MAXMSGL(104857600)
HBINT(300) SCYEXIT( ) SCYDATA( ) SENDEXIT( ) SENDDATA( ) RCVEXIT( ) RCVDATA( )
COMPHDR(NONE) COMPMSG(NONE) SSLCIPH( ) SSLPEER( ) SHARECNV(10) CLNTWGHT(0) AFFINITY(PREFERRED)
DEFRECON(NO) ALTDATE(2016-07-11) ALTTIME(16.22.12)
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.DEF.CLNTCONN) CHLTYPE(CLNTCONN) DESCR( ) TRPTYPE(TCP) CONNAME( ) QMNAME( )
LOCLADDR( ) USERID( ) PASSWORD( ) MODENAME( ) TPNAME( ) MAXMSGL(104857600) HBINT(300)
SCYEXIT( ) SCYDATA( ) SENDEXIT( ) SENDDATA( ) RCVEXIT( ) RCVDATA( ) COMPHDR(NONE)
COMPMSG(NONE) SSLCIPH( ) SSLPEER( ) SHARECNV(10) CLNTWGHT(0) AFFINITY(PREFERRED) DEFRECON(NO)
ALTDATE(2013-02-19) ALTTIME(17.29.55) |
|
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jul 12, 2016 2:09 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| blorro wrote: |
| ...i've tried using sample program "amqsputc" but keep getting "MQRC_Q_MGR_NAME_ERROR"... |
What are you specifying as a queue manager name when you pass it to amqsputc? What is the actual name of the queue manager you're trying to connect to?
By the way, I edited your previous post to make it a little easier to read...
_________________
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 |
|
|
| blorro |
| Posted: Tue Jul 12, 2016 2:30 am Post subject: |
|
|
Acolyte
Joined: 09 Jan 2014
Posts: 57
Location: Sweden
|
Thanks for cleaning up, and forgot to add my connection attempt.:
I've tried :
amqsputc QUEUE1 *QMDMZTST'
amqsputc QUEUE1 *QMDMZTST"
amqsputc QUEUE1 ' '
amqsputc QUEUE1 ""
And also the same with "amqsphac" sample program.
All of these attempts end up with MQRC 2058 as mentioned before.
MQClient.ini is not used, although i have tried that aswell, pointing to a single queuemanager and that worked , so connectivity is there.
It's me , not CCDT =) |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jul 12, 2016 2:33 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| blorro wrote: |
I've tried :
amqsputc QUEUE1 *QMDMZTST'
amqsputc QUEUE1 *QMDMZTST" |
Lose the trailing single/double quote and try again.
_________________
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 |
|
|
| blorro |
| Posted: Tue Jul 12, 2016 3:57 am Post subject: |
|
|
Acolyte
Joined: 09 Jan 2014
Posts: 57
Location: Sweden
|
Forgot to mention i tried that already.
"E:\apps\MQ>amqsphac AQP.DMZ.WDETEST *QMDMZTST
Sample AMQSPHAC start
MQCONNX ended with reason code 2058
Sample AMQSPHAC end"
CCDT file is created on a MQ Server version 7.0.1
MQ Servers where queues and channels are created are also 7.0.1.
MQ client is 8.0.0.4. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jul 12, 2016 4:54 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| blorro wrote: |
Forgot to mention i tried that already.
"E:\apps\MQ>amqsphac AQP.DMZ.WDETEST *QMDMZTST
Sample AMQSPHAC start
MQCONNX ended with reason code 2058
Sample AMQSPHAC end"
CCDT file is created on a MQ Server version 7.0.1
MQ Servers where queues and channels are created are also 7.0.1.
MQ client is 8.0.0.4. |
If the client is 8.0.0.4 you may want to create the CCDT at 8.0.0.4 as well.
I have had poor experience with V8 and CCDTs at V7.x ... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| blorro |
| Posted: Tue Jul 12, 2016 5:16 am Post subject: |
|
|
Acolyte
Joined: 09 Jan 2014
Posts: 57
Location: Sweden
|
Ok , i might as well try that.
Just thought i'd be on the safe side based on the info posted in KB docs.
"Newer versions of the MQ clients (such as 8.0) know how to handle CCDT files that were created/edited by older queue managers (such as 6.0)
Older MQ clients (such as 6.0) do NOT know how to handle CCDT files that were created/edited by newer queue managers (such as 8.0). That is, older clients do not know what are the new attributes (if any) introduced in newer MQ versions.
Based on the above, if you have a mix of versions of MQ clients that use a common CCDT file, then this CCDT file should be edited from a queue manager at the LOWEST (OLDEST) version. For example, if you are using MQ 6.0, 7.0, 7.1, 7.5 and 8.0 clients that use a CCDT file, then the CCDT file must be maintained by the MQ queue manager at version 6.0
- However, the newer MQ clients (8.0) when using the CCDT created with 5.3 will NOT be able to fully exploit newer features, even when connecting to an 8.0 queue manager because the CCDT will not show the new attributes for those new features.
MQ CCDT created version Compatible MQ client versions
6.0 6.0 7.0 7.1 7.5 8.0
7.0 7.0 7.1 7.5 8.0 " |
|
| Back to top |
|
|
| blorro |
| Posted: Tue Jul 12, 2016 5:39 am Post subject: |
|
|
Acolyte
Joined: 09 Jan 2014
Posts: 57
Location: Sweden
|
So recreated CCDT file on a 8.0.0.4 Queuemanager.
Still got the same error MQRC 2058.
Tried two different options, one where conname on Client connection pointed towards actual server names and one where Queuemanager names were used.
Queuemanager group name was left unchanged.
I must be missing something obvious here. |
|
| Back to top |
|
|
|
|
