Mark Akerman | 21 Nov 21:41 2014
Picon

MO71 queue statistics


All,

Quick question for the list.

What MQ authorizations should we assign to the queue to be able to pull
statistics off the queue using MO71?

Thanks,

Mark

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Tim Zielke | 20 Nov 21:40 2014

Re: selecting channel from CCDT

Hi Frank,

 

Did you check tools\c\samples\Bin64? 

 

Thanks,

Tim

 

Tim Zielke | CICS/MQ Systems Programmer

Aon Service Corporation | Aon Technology | Enterprise Architecture and Engineering

4 Overlook Point, Lincolnshire, IL 60069 

t +1.847.295.5000

tim.zielke <at> aon.com

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Frank Swarbrick
Sent: Thursday, November 20, 2014 2:25 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: selecting channel from CCDT

 

I don't find amqscnxc in the tools\c\samples\bin library with the others. Is there anywhere I can download the (Windows) executable from?

 

As for the CipherSpec, I wasn't involved in choosing this one, and I don't know why it was chosen.  I will try and find out and see about getting it changed.

 

Thanks!

 

From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay <at> THEHARTFORD.COM>
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Sent: Thursday, November 20, 2014 5:17 AM
Subject: Re: selecting channel from CCDT

 

Frank,

For testing channel tables, or any other tests that focus on the connection attempt, take a look at the amqscnxc sample program in place of amqsputc. All amqscnxc does is connect, issue an MQINQ command to get the QM name, and disconnect. Since its not attempting to open any queues, it avoids any complications that may arise at that step (q doesn’t exist, no access to the queue) that can muddy the waters when testing the connectivity, but have no relevance on your test results.

 

If you have the opportunity to influence the choice of CipherSpec to use (I notice a vendor is involved in your scenario so you may not), don’t use the one you mentioned. Take a look at the chart here:

 

Notice the one you mentioned, ‘RC4_MD5_US’, uses SSL 3.0 and MD5, both which are now considered no longer secure.

 

 

I hope I've given enough detail (too much?) so that others with this issue can resolve it.

I appreciate the detail you provided. I look at some of my earliest posts here and on mqseries.net (good god, over 12 years ago), and some of the longest ones were related to channel tables! They are not as simple as one would think. I suppose because they are so flexible and offer so many options.

 

 

Peter Potkay

Application Platform Engineering <at> The Hartford

Websphere MQ, Message Broker and DataPower

 

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Frank Swarbrick
Sent: Thursday, November 20, 2014 4:29 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: selecting channel from CCDT

 

With the help of Paul Clarke I believe I now have what I need to accomplish my goal.  My goal being:

Allow a vendor MQI client application to connect to MQ Manager MQD1 using SSLCIPH RC4_MD5_US using one of two channels named PRMRT and PRMNRT. 

 

Paul's idea was to have each client channel specify its own unique QMNAME, and for the client application to connect to the desired channel utilizing the asterisk (*) prefix.  This latter item is required so that when the server returns a QMNAME that is different than the QMNAME specified on the client channel the client will not reject the connection because of this.

 

As part of my "proof of concept" test I also defined two additional channels:  DEFAULT (no SSL) and SSL.  The z/OS job used to define both the server and client channels, as well as the CCDT to be used by the clients is as follows:

 

//MQCLIENT JOB ,'MQ DEFINE CLIENTS',NOTIFY=&SYSUID                     
//         SET QMGR=MQD1                                               
//CSQUTIL  EXEC PGM=CSQUTIL,PARM=&QMGR                                 
//STEPLIB  DD DISP=SHR,DSN=CSQ.SCSQANLE                                
//         DD DISP=SHR,DSN=CSQ.SCSQAUTH                                
//SYSPRINT DD SYSOUT=*                                                 
//SYSIN    DD *                                                        
COMMAND DDNAME(SVRCONN)                                                
COMMAND DDNAME(CLNTCONN)                                               
COMMAND DDNAME(MAKECCDT) MAKECLNT(CLCHL)                               
/*                                                                     
//SVRCONN DD *                                                         
DEFINE CHANNEL(DEFAULT) CHLTYPE(SVRCONN)                               +
    MCAUSER(DVFJS)                                                     +
    SSLCAUTH(OPTIONAL)                                                 +
    TRPTYPE(TCP)                                                       
DEFINE CHANNEL(SSL) CHLTYPE(SVRCONN)                                   +
    MCAUSER(DVFJS)                                                     +
    SSLCIPH(RC4_MD5_US)                                                +
    SSLCAUTH(OPTIONAL)                                                 +
    TRPTYPE(TCP)                                                       
DEFINE CHANNEL(PRMRT) CHLTYPE(SVRCONN)                                 +
    MCAUSER(PRMSERVI)                                                  +
    SSLCIPH(RC4_MD5_US)                                                +
    SSLCAUTH(OPTIONAL)                                                 +
    TRPTYPE(TCP)                                                       
DEFINE CHANNEL(PRMNRT) CHLTYPE(SVRCONN)                                +
    MCAUSER(PRMSERVI)                                                  +
    SSLCIPH(RC4_MD5_US)                                                +
    SSLCAUTH(OPTIONAL)                                                 +
    TRPTYPE(TCP)                                                       
/*                                                                     
//CLNTCONN DD *                                                        
DEFINE CHANNEL(DEFAULT) CHLTYPE(CLNTCONN)                              +
    QMNAME(MQD1)                                                       +
    TRPTYPE(TCP) CONNAME('zosd.fb(1414)')                              
DEFINE CHANNEL(SSL) CHLTYPE(CLNTCONN)                                  +
    QMNAME(MQD1SSL)                                                    +
    SSLCIPH(RC4_MD5_US)                                                +
    TRPTYPE(TCP) CONNAME('zosd.fb(1414)')                              
DEFINE CHANNEL(PRMRT) CHLTYPE(CLNTCONN)                                +
    QMNAME(MQD1RT)                                                     +
    SSLCIPH(RC4_MD5_US)                                                +
    TRPTYPE(TCP) CONNAME('zosd.fb(1414)')                              
DEFINE CHANNEL(PRMNRT) CHLTYPE(CLNTCONN)                               +
    QMNAME(MQD1NRT)                                                    +
    SSLCIPH(RC4_MD5_US)                                                +
    TRPTYPE(TCP) CONNAME('zosd.fb(1414)')                              
/*                                                                     
//MAKECCDT DD *                             
DISPLAY CHANNEL(*) ALL TYPE(CLNTCONN)       
/*                                          
//CLCHL    DD PATH='/u/dvfjs/clchl_mqd1.tab',
//            PATHOPTS=(OWRONLY,OCREAT,OTRUNC
//            PATHMODE=(SIRUSR,SIWUSR),     
//            FILEDATA=BINARY               
//

 

File /u/dvfjs/clchl_mqd1.tab is copied to the client machine and is referenced with the following data in mqclient.ini:

 

# start of mqclient.ini

Channels:
   ChannelDefinitionDirectory=c:\mqm         
   ChannelDefinitionFile=clchl_mqd1.tab      

SSL:
   SSLKeyRepository=c:\mqm\fjs4
   SSLKeyResetCount=1048576                  
   SSLHTTPProxyName=data-httpfilter.fb(8080) 
   OCSPAuthentication=WARN                   

# end of mqclient.ini

 

Tests were done using the AMQSPUT0 sample application.

 

Test 1: Specify MQName MQD1

 

C:\mqm>amqsputc Q1 MQD1
Sample AMQSPUT0 start
target queue is Q1
test

Sample AMQSPUT0 end

 

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel DEFAULT started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel DEFAULT no longer active connection 10.100.5.50

 

Notes: We connected to the MQD1 manager on channel "DEFAULT", as expected.
--------------------------------------------------------------------------------

Test 2: Specify MQName *MQD1

 

C:\mqm>amqsputc Q1 *MQD1
Sample AMQSPUT0 start
target queue is Q1
test

Sample AMQSPUT0 end

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel DEFAULT started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel DEFAULT no longer active connection 10.100.5.50

 

Notes: Same as test 1.
--------------------------------------------------------------------------------

Test 3: Specify MQName MQD1SSL to (attempt to) connect using channel SSL.

 

C:\mqm>amqsputc Q1 MQD1SSL
Sample AMQSPUT0 start
MQCONNX ended with reason code 2058

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel SSL started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel SSL no longer active connection 10.100.5.50

 

Notes: Because we connected to the queue manager named MQD1 but we requested a queue manager named MQD1SSL the client terminated with reason code 2058.
--------------------------------------------------------------------------------

Test 4: Specify MQName *MQD1SSL to (successfully) connect using channel SSL.

 

C:\mqm>amqsputc Q1 *MQD1SSL
Sample AMQSPUT0 start
target queue is Q1
test

Sample AMQSPUT0 end

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel SSL started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel SSL no longer active connection 10.100.5.50

 

Notes: Because we connected to '*MQD1SSL' instead of just 'MQD1SSL' the client ignored the fact that the queue manager that was connected to did not have the same name as the queue manager requested.
--------------------------------------------------------------------------------

Test 5: Specify MQName *MQD1RT to connect using channel PRMRT.


C:\mqm>amqsputc Q1 *MQD1RT
Sample AMQSPUT0 start
target queue is Q1

Sample AMQSPUT0 end

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel PRMRT started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel PRMRT no longer active connection 10.100.5.50

 

Notes: Just another example of using the asterisk to get around the QMNAME mismatch issue.
--------------------------------------------------------------------------------

Test 6: Specify MQName *MQD1NRT to connect using channel PRMNRT.

 

C:\mqm>amqsputc Q1 *MQD1NRT
Sample AMQSPUT0 start
target queue is Q1
haha

Sample AMQSPUT0 end

+CSQX500I :MQD1 CSQXRESP Channel PRMNRT started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel PRMNRT no longer active connection 10.100.5.50

 

Notes: Final another example of using the asterisk to get around the QMNAME mismatch issue.
--------------------------------------------------------------------------------

In the end it seems to me that MQ should support something a bit (!!) more straight forward to accomplish this.  But it does work.  So yay!  I'm thinking of what should go in an RFE to enhance this so its simpler (and more obvious) how a particular channel can be selected by a client.

 

Thanks to Paul and others who gave their input on this issue.  I hope I've given enough detail (too much?) so that others with this issue can resolve it.

 

Frank Swarbrick

Mainframe Applications Development Architect

FirstBank - Lakewood, CO  USA

 

From: Dave Corbett <DAVID.CORBETT <at> USBANK.COM>
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Sent: Tuesday, November 18, 2014 1:08 PM
Subject: Re: selecting channel from CCDT

 

Frank,

You are getting to one of the reasons I do not like channel tables at all.  I have many application servers in my environment.  Each of those app servers can host many different applications (an app server!).  I want each of the applications to use a unique channel name so that I can identify them at the QMGR when I look at all of the SVRCONN connections I have.  Each application is deployed on multiple servers, so for channel tables to work, I would have to provide a unique channel table for each application that only has their channel name in it, an administrative nightmare with just that, and then I would need to have their unique channel table deployed to multiple servers.  And then, when I have a farm of MQ servers (each with a uniquely defined QMGR name) that are clones of each other, and I want the connections to be sprayed across each of them somewhat evenly, I need to use the CLNTWGHT parameter - but each channel will stand on its own because it has its own channel table and therefore cannot be balanced based on the number of connections used by the other apps connecting to that MQ server (I know - if each table has CLNTWGHT set to the same value, then each client should theoretically be balanced, and therefore the total server conns would be balanced).  But there are other issues involved as well.  These apps are typically JMS based request / reply driven and need to get their particular response from the same QMGR they sent their request to.  However, the app server's implementation of JMS uses a unique connection for both the request / response and therefore need to be pointed to the same place.  I cannot do that with channel tables and CLNTWGHT parameters.  My particular situation is a "farm" of MQ servers that front end a mainframe.

I had to go down a different load balancing path - F5 - which creates its own unique set of issues, but I find those more palatable than the generation and distribution of client channel tables.

Thanks,
David Corbett
Work:  612-973-7086
Pager: 612-280-6307
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0




From:        Frank Swarbrick <00000006cad63953-dmarc-request <at> LISTSERV.MEDUNIWIEN.AC.AT>
To:        MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT,
Date:        11/18/2014 12:46 PM
Subject:        Re: selecting channel from CCDT
Sent by:        MQSeries List <MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT>




That is indeed the behavior I am seeing.  Maybe I am simply not understanding.  Do all the clients that look at the same CCDT file use the same channel?  What is the point of having multiple client channel definitions (pointing to the same QMGR) if you cannot (apparently) use them?  I guess maybe I'm not understanding how channels are to be used.  The way it's been set up (not by me) is that each client uses a different channel.  I'm not sure why it was set up that way.  It could be that person understood it about as well as I (i.e.: not very well).

We are brand new to MQ so perhaps we've not yet obtained the knowledge we need.

From: Paul Clarke <paul.clarke85 <at> BTINTERNET.COM>
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Sent: Tuesday, November 18, 2014 11:22 AM
Subject: Re: selecting channel from CCDT


Frank,
 
What behaviour were you looking for? By default MQ will select the first channel, alphabetically, that has a QMNAME value equal to the value specified on the connection.
 
However, if you want to spread your connections across multiple channels then you should also play with the CLNTWGHT parameter. Since yours all appear to be 0 you get the ordered behaviour already mentioned. However, if you set them all to, say, 10, then you will get a spread across all the channels if this CCDT is used by multiple clients. If you want a spread even for the same client (which is generally unusual) then you need to also set AFFINITY(NONE).
 
These are, naturally, all described in greater detail in the manual.
 
Cheers,
Paul.
 
Paul Clarke

MQGem Software Limited
IBM Business Partner
www.mqgem.com
 


From: Frank Swarbrick
Sent: Tuesday, November 18, 2014 5:56 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: selecting channel from CCDT
 
I must be missing something very obvious, but I can't figure out how a client can selects a particular channel from a CCDT.  It always appears to simple select the first channel that it finds in the CCDT file.
 
Specifically, here is the results of displaying the channels using the mqsc utility:
 
C:\mqm>mqsc -n -t c:\mqm\clchl_mqd1.tab
>dis channel(*)
AMQ8414: Display Channel details.
CHANNEL(FJS.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        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(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(FS2.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )          SHARECNV(10)        CLNTWGHT(0)
AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(MQD1.2D_AS02.PRMNRT)            CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(PRM)        CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )         USERID( )
PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )         SENDDATA( )
RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)                  SHARECNV(10)
CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(SSL.CLIENTS)                    CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)
LOCLADDR(10.100.5.50)                   USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )
SCYDATA( )          SENDEXIT( )         SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)

 
 
It's always connecting me using the channel named FJS.EXPLORER.SVRCONN.
 
I'm using the following mqclient.ini file:
 
ClientExitPath:
  ExitsDefaultPath=C:\Program Files (x86)\IBM\WebSphere MQ\exits
  ExitsDefaultPath64=C:\Program Files (x86)\IBM\WebSphere MQ\exits64

Channels:
  ChannelDefinitionDirectory=c:\mqm          
  ChannelDefinitionFile=clchl_mqd1.tab      

SSL:
  SSLKeyRepository=c:\mqm\fjs4
  SSLHTTPProxyName=data-httpfilter.fb(8080)  
  SSLKeyResetCount=1048576                  
  OCSPAuthentication=WARN                    

 
What am I missing?

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com



List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com



U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.

 



---------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Paul Clarke | 20 Nov 14:28 2014

Re: selecting channel from CCDT

That’s good news Frank, I’m glad it all worked out for you. I agree that at first glance it can seem a little convoluted but it’s actually fairly straightforward. I suspect that a fair big of the complexity is actually creating the CCDT on z/OS with a batch job. Did you know that you can do this locally on the same machine as the client using SupportPac MO72 or MQGem’s MQSCX product  or indeed, if the you have MQ V8 client installed, directly using the MQ client install.
 
As for making it simpler it would be interesting if you come up with something. In many respects the current design deliberately shields the application from the complexities of having to know anything at all about channels. An application provides a Queue Manager name and nothing else. There is clearly a limit to what one can do with such little information. Of course if the application is fully knowledgeable about the backend servers and the channels then it can, as was mentioned previously, just pass in the channel definition to use directly on the MQCONN verb. However, this mechanism leaves the applications uncluttered with such concerns and puts all the configuration down into the CCDT. You could, of course, achieve a similar effect using a PreConnect exit and some sort of central repository (such as LDAP). This would alleviate the problem of having to distribute the CCDT to all your clients.
 
Regards,
Paul.
 
Paul Clarke

MQGem Software Limited
IBM Business Partner
www.mqgem.com
 
Sent: Thursday, November 20, 2014 9:28 AM
Subject: Re: selecting channel from CCDT
 
With the help of Paul Clarke I believe I now have what I need to accomplish my goal.  My goal being:
Allow a vendor MQI client application to connect to MQ Manager MQD1 using SSLCIPH RC4_MD5_US using one of two channels named PRMRT and PRMNRT. 
 
Paul's idea was to have each client channel specify its own unique QMNAME, and for the client application to connect to the desired channel utilizing the asterisk (*) prefix.  This latter item is required so that when the server returns a QMNAME that is different than the QMNAME specified on the client channel the client will not reject the connection because of this.
 
As part of my "proof of concept" test I also defined two additional channels:  DEFAULT (no SSL) and SSL.  The z/OS job used to define both the server and client channels, as well as the CCDT to be used by the clients is as follows:
 
//MQCLIENT JOB ,'MQ DEFINE CLIENTS',NOTIFY=&SYSUID                     
//         SET QMGR=MQD1                                               
//CSQUTIL  EXEC PGM=CSQUTIL,PARM=&QMGR                                 
//STEPLIB  DD DISP=SHR,DSN=CSQ.SCSQANLE                                
//         DD DISP=SHR,DSN=CSQ.SCSQAUTH                                
//SYSPRINT DD SYSOUT=*                                                 
//SYSIN    DD *                                                        
COMMAND DDNAME(SVRCONN)                                                
COMMAND DDNAME(CLNTCONN)                                               
COMMAND DDNAME(MAKECCDT) MAKECLNT(CLCHL)                               
/*                                                                     
//SVRCONN DD *                                                         
DEFINE CHANNEL(DEFAULT) CHLTYPE(SVRCONN)                               +
    MCAUSER(DVFJS)                                                     +
    SSLCAUTH(OPTIONAL)                                                 +
    TRPTYPE(TCP)                                                       
DEFINE CHANNEL(SSL) CHLTYPE(SVRCONN)                                   +
    MCAUSER(DVFJS)                                                     +
    SSLCIPH(RC4_MD5_US)                                                +
    SSLCAUTH(OPTIONAL)                                                 +
    TRPTYPE(TCP)                                                       
DEFINE CHANNEL(PRMRT) CHLTYPE(SVRCONN)                                 +
    MCAUSER(PRMSERVI)                                                  +
    SSLCIPH(RC4_MD5_US)                                                +
    SSLCAUTH(OPTIONAL)                                                 +
    TRPTYPE(TCP)                                                       
DEFINE CHANNEL(PRMNRT) CHLTYPE(SVRCONN)                                +
    MCAUSER(PRMSERVI)                                                  +
    SSLCIPH(RC4_MD5_US)                                                +
    SSLCAUTH(OPTIONAL)                                                 +
    TRPTYPE(TCP)                                                       
/*                                                                     
//CLNTCONN DD *                                                        
DEFINE CHANNEL(DEFAULT) CHLTYPE(CLNTCONN)                              +
    QMNAME(MQD1)                                                       +
    TRPTYPE(TCP) CONNAME('zosd.fb(1414)')                              
DEFINE CHANNEL(SSL) CHLTYPE(CLNTCONN)                                  +
    QMNAME(MQD1SSL)                                                    +
    SSLCIPH(RC4_MD5_US)                                                +
    TRPTYPE(TCP) CONNAME('zosd.fb(1414)')                              
DEFINE CHANNEL(PRMRT) CHLTYPE(CLNTCONN)                                +
    QMNAME(MQD1RT)                                                     +
    SSLCIPH(RC4_MD5_US)                                                +
    TRPTYPE(TCP) CONNAME('zosd.fb(1414)')                              
DEFINE CHANNEL(PRMNRT) CHLTYPE(CLNTCONN)                               +
    QMNAME(MQD1NRT)                                                    +
    SSLCIPH(RC4_MD5_US)                                                +
    TRPTYPE(TCP) CONNAME('zosd.fb(1414)')                              
/*                                                                     
//MAKECCDT DD *                             
DISPLAY CHANNEL(*) ALL TYPE(CLNTCONN)       
/*                                          
//CLCHL    DD PATH='/u/dvfjs/clchl_mqd1.tab',
//            PATHOPTS=(OWRONLY,OCREAT,OTRUNC
//            PATHMODE=(SIRUSR,SIWUSR),     
//            FILEDATA=BINARY               
//
 
File /u/dvfjs/clchl_mqd1.tab is copied to the client machine and is referenced with the following data in mqclient.ini:
 
# start of mqclient.ini
Channels:
   ChannelDefinitionDirectory=c:\mqm         
   ChannelDefinitionFile=clchl_mqd1.tab      

SSL:
   SSLKeyRepository=c:\mqm\fjs4
   SSLKeyResetCount=1048576                  
   SSLHTTPProxyName=data-httpfilter.fb(8080) 
   OCSPAuthentication=WARN                   
# end of mqclient.ini
 
Tests were done using the AMQSPUT0 sample application.
 
Test 1: Specify MQName MQD1
 
C:\mqm>amqsputc Q1 MQD1
Sample AMQSPUT0 start
target queue is Q1
test

Sample AMQSPUT0 end
 
Server log results:
+CSQX500I :MQD1 CSQXRESP Channel DEFAULT started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel DEFAULT no longer active connection 10.100.5.50
 
Notes: We connected to the MQD1 manager on channel "DEFAULT", as expected.
--------------------------------------------------------------------------------
Test 2: Specify MQName *MQD1
 
C:\mqm>amqsputc Q1 *MQD1
Sample AMQSPUT0 start
target queue is Q1
test

Sample AMQSPUT0 end

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel DEFAULT started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel DEFAULT no longer active connection 10.100.5.50
 
Notes: Same as test 1.
--------------------------------------------------------------------------------
Test 3: Specify MQName MQD1SSL to (attempt to) connect using channel SSL.
 
C:\mqm>amqsputc Q1 MQD1SSL
Sample AMQSPUT0 start
MQCONNX ended with reason code 2058

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel SSL started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel SSL no longer active connection 10.100.5.50
 
Notes: Because we connected to the queue manager named MQD1 but we requested a queue manager named MQD1SSL the client terminated with reason code 2058.
--------------------------------------------------------------------------------
Test 4: Specify MQName *MQD1SSL to (successfully) connect using channel SSL.
 
C:\mqm>amqsputc Q1 *MQD1SSL
Sample AMQSPUT0 start
target queue is Q1
test

Sample AMQSPUT0 end

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel SSL started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel SSL no longer active connection 10.100.5.50
 
Notes: Because we connected to '*MQD1SSL' instead of just 'MQD1SSL' the client ignored the fact that the queue manager that was connected to did not have the same name as the queue manager requested.
--------------------------------------------------------------------------------
Test 5: Specify MQName *MQD1RT to connect using channel PRMRT.

C:\mqm>amqsputc Q1 *MQD1RT
Sample AMQSPUT0 start
target queue is Q1

Sample AMQSPUT0 end

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel PRMRT started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel PRMRT no longer active connection 10.100.5.50
 
Notes: Just another example of using the asterisk to get around the QMNAME mismatch issue.
--------------------------------------------------------------------------------
Test 6: Specify MQName *MQD1NRT to connect using channel PRMNRT.
 
C:\mqm>amqsputc Q1 *MQD1NRT
Sample AMQSPUT0 start
target queue is Q1
haha

Sample AMQSPUT0 end

+CSQX500I :MQD1 CSQXRESP Channel PRMNRT started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel PRMNRT no longer active connection 10.100.5.50
 
Notes: Final another example of using the asterisk to get around the QMNAME mismatch issue.
--------------------------------------------------------------------------------

In the end it seems to me that MQ should support something a bit (!!) more straight forward to accomplish this.  But it does work.  So yay!  I'm thinking of what should go in an RFE to enhance this so its simpler (and more obvious) how a particular channel can be selected by a client.
 
Thanks to Paul and others who gave their input on this issue.  I hope I've given enough detail (too much?) so that others with this issue can resolve it.
 
Frank Swarbrick
Mainframe Applications Development Architect
FirstBank - Lakewood, CO  USA
 
From: Dave Corbett <DAVID.CORBETT-nU+plvizqFRXrIkS9f7CXA@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org
Sent: Tuesday, November 18, 2014 1:08 PM
Subject: Re: selecting channel from CCDT
 
Frank,

You are getting to one of the reasons I do not like channel tables at all.  I have many application servers in my environment.  Each of those app servers can host many different applications (an app server!).  I want each of the applications to use a unique channel name so that I can identify them at the QMGR when I look at all of the SVRCONN connections I have.  Each application is deployed on multiple servers, so for channel tables to work, I would have to provide a unique channel table for each application that only has their channel name in it, an administrative nightmare with just that, and then I would need to have their unique channel table deployed to multiple servers.  And then, when I have a farm of MQ servers (each with a uniquely defined QMGR name) that are clones of each other, and I want the connections to be sprayed across each of them somewhat evenly, I need to use the CLNTWGHT parameter - but each channel will stand on its own because it has its own channel table and therefore cannot be balanced based on the number of connections used by the other apps connecting to that MQ server (I know - if each table has CLNTWGHT set to the same value, then each client should theoretically be balanced, and therefore the total server conns would be balanced).  But there are other issues involved as well.  These apps are typically JMS based request / reply driven and need to get their particular response from the same QMGR they sent their request to.  However, the app server's implementation of JMS uses a unique connection for both the request / response and therefore need to be pointed to the same place.  I cannot do that with channel tables and CLNTWGHT parameters.  My particular situation is a "farm" of MQ servers that front end a mainframe.

I had to go down a different load balancing path - F5 - which creates its own unique set of issues, but I find those more palatable than the generation and distribution of client channel tables.

Thanks,
David Corbett
Work:  612-973-7086
Pager: 612-280-6307
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0



From:        Frank Swarbrick <00000006cad63953-dmarc-request-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org>
To:        MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org,
Date:        11/18/2014 12:46 PM
Subject:        Re: selecting channel from CCDT
Sent by:        MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org>



That is indeed the behavior I am seeing.  Maybe I am simply not understanding.  Do all the clients that look at the same CCDT file use the same channel?  What is the point of having multiple client channel definitions (pointing to the same QMGR) if you cannot (apparently) use them?  I guess maybe I'm not understanding how channels are to be used.  The way it's been set up (not by me) is that each client uses a different channel.  I'm not sure why it was set up that way.  It could be that person understood it about as well as I (i.e.: not very well).

We are brand new to MQ so perhaps we've not yet obtained the knowledge we need.

From: Paul Clarke <paul.clarke85-C2P5NI4ZpDVm9/pnFjKg3w@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org
Sent: Tuesday, November 18, 2014 11:22 AM
Subject: Re: selecting channel from CCDT

Frank,
 
What behaviour were you looking for? By default MQ will select the first channel, alphabetically, that has a QMNAME value equal to the value specified on the connection.
 
However, if you want to spread your connections across multiple channels then you should also play with the CLNTWGHT parameter. Since yours all appear to be 0 you get the ordered behaviour already mentioned. However, if you set them all to, say, 10, then you will get a spread across all the channels if this CCDT is used by multiple clients. If you want a spread even for the same client (which is generally unusual) then you need to also set AFFINITY(NONE).
 
These are, naturally, all described in greater detail in the manual.
 
Cheers,
Paul.
 
Paul Clarke

MQGem Software Limited
IBM Business Partner
www.mqgem.com
 


From: Frank Swarbrick
Sent: Tuesday, November 18, 2014 5:56 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org
Subject: selecting channel from CCDT
 
I must be missing something very obvious, but I can't figure out how a client can selects a particular channel from a CCDT.  It always appears to simple select the first channel that it finds in the CCDT file.
 
Specifically, here is the results of displaying the channels using the mqsc utility:
 
C:\mqm>mqsc -n -t c:\mqm\clchl_mqd1.tab
>dis channel(*)
AMQ8414: Display Channel details.
CHANNEL(FJS.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        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(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(FS2.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )          SHARECNV(10)        CLNTWGHT(0)
AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(MQD1.2D_AS02.PRMNRT)            CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(PRM)        CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )         USERID( )
PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )         SENDDATA( )
RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)                  SHARECNV(10)
CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(SSL.CLIENTS)                    CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)
LOCLADDR(10.100.5.50)                   USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )
SCYDATA( )          SENDEXIT( )         SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
 
 
It's always connecting me using the channel named FJS.EXPLORER.SVRCONN.
 
I'm using the following mqclient.ini file:
 
ClientExitPath:
  ExitsDefaultPath=C:\Program Files (x86)\IBM\WebSphere MQ\exits
  ExitsDefaultPath64=C:\Program Files (x86)\IBM\WebSphere MQ\exits64

Channels:
  ChannelDefinitionDirectory=c:\mqm         
  ChannelDefinitionFile=clchl_mqd1.tab      

SSL:
  SSLKeyRepository=c:\mqm\fjs4
  SSLHTTPProxyName=data-httpfilter.fb(8080) 
  SSLKeyResetCount=1048576                  
  OCSPAuthentication=WARN                   
 
What am I missing?

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com




List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.




---------------------------------------------------------------------
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com



List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Re: selecting channel from CCDT

Frank,

For testing channel tables, or any other tests that focus on the connection attempt, take a look at the amqscnxc sample program in place of amqsputc. All amqscnxc does is connect, issue an MQINQ command to get the QM name, and disconnect. Since its not attempting to open any queues, it avoids any complications that may arise at that step (q doesn’t exist, no access to the queue) that can muddy the waters when testing the connectivity, but have no relevance on your test results.

 

If you have the opportunity to influence the choice of CipherSpec to use (I notice a vendor is involved in your scenario so you may not), don’t use the one you mentioned. Take a look at the chart here:

http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.sec.doc/q014260_.htm

 

Notice the one you mentioned, ‘RC4_MD5_US’, uses SSL 3.0 and MD5, both which are now considered no longer secure.

 

 

I hope I've given enough detail (too much?) so that others with this issue can resolve it.

I appreciate the detail you provided. I look at some of my earliest posts here and on mqseries.net (good god, over 12 years ago), and some of the longest ones were related to channel tables! They are not as simple as one would think. I suppose because they are so flexible and offer so many options.

 

 

Peter Potkay

Application Platform Engineering <at> The Hartford

Websphere MQ, Message Broker and DataPower

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Frank Swarbrick
Sent: Thursday, November 20, 2014 4:29 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: selecting channel from CCDT

 

With the help of Paul Clarke I believe I now have what I need to accomplish my goal.  My goal being:

Allow a vendor MQI client application to connect to MQ Manager MQD1 using SSLCIPH RC4_MD5_US using one of two channels named PRMRT and PRMNRT. 

 

Paul's idea was to have each client channel specify its own unique QMNAME, and for the client application to connect to the desired channel utilizing the asterisk (*) prefix.  This latter item is required so that when the server returns a QMNAME that is different than the QMNAME specified on the client channel the client will not reject the connection because of this.

 

As part of my "proof of concept" test I also defined two additional channels:  DEFAULT (no SSL) and SSL.  The z/OS job used to define both the server and client channels, as well as the CCDT to be used by the clients is as follows:

 

//MQCLIENT JOB ,'MQ DEFINE CLIENTS',NOTIFY=&SYSUID                     
//         SET QMGR=MQD1                                               
//CSQUTIL  EXEC PGM=CSQUTIL,PARM=&QMGR                                 
//STEPLIB  DD DISP=SHR,DSN=CSQ.SCSQANLE                                
//         DD DISP=SHR,DSN=CSQ.SCSQAUTH                                
//SYSPRINT DD SYSOUT=*                                                 
//SYSIN    DD *                                                        
COMMAND DDNAME(SVRCONN)                                                
COMMAND DDNAME(CLNTCONN)                                               
COMMAND DDNAME(MAKECCDT) MAKECLNT(CLCHL)                               
/*                                                                     
//SVRCONN DD *                                                         
DEFINE CHANNEL(DEFAULT) CHLTYPE(SVRCONN)                               +
    MCAUSER(DVFJS)                                                     +
    SSLCAUTH(OPTIONAL)                                                 +
    TRPTYPE(TCP)                                                       
DEFINE CHANNEL(SSL) CHLTYPE(SVRCONN)                                   +
    MCAUSER(DVFJS)                                                     +
    SSLCIPH(RC4_MD5_US)                                                +
    SSLCAUTH(OPTIONAL)                                                 +
    TRPTYPE(TCP)                                                       
DEFINE CHANNEL(PRMRT) CHLTYPE(SVRCONN)                                 +
    MCAUSER(PRMSERVI)                                                  +
    SSLCIPH(RC4_MD5_US)                                                +
    SSLCAUTH(OPTIONAL)                                                 +
    TRPTYPE(TCP)                                                       
DEFINE CHANNEL(PRMNRT) CHLTYPE(SVRCONN)                                +
    MCAUSER(PRMSERVI)                                                  +
    SSLCIPH(RC4_MD5_US)                                                +
    SSLCAUTH(OPTIONAL)                                                 +
    TRPTYPE(TCP)                                                       
/*                                                                     
//CLNTCONN DD *                                                        
DEFINE CHANNEL(DEFAULT) CHLTYPE(CLNTCONN)                              +
    QMNAME(MQD1)                                                       +
    TRPTYPE(TCP) CONNAME('zosd.fb(1414)')                              
DEFINE CHANNEL(SSL) CHLTYPE(CLNTCONN)                                  +
    QMNAME(MQD1SSL)                                                    +
    SSLCIPH(RC4_MD5_US)                                                +
    TRPTYPE(TCP) CONNAME('zosd.fb(1414)')                              
DEFINE CHANNEL(PRMRT) CHLTYPE(CLNTCONN)                                +
    QMNAME(MQD1RT)                                                     +
    SSLCIPH(RC4_MD5_US)                                                +
    TRPTYPE(TCP) CONNAME('zosd.fb(1414)')                              
DEFINE CHANNEL(PRMNRT) CHLTYPE(CLNTCONN)                               +
    QMNAME(MQD1NRT)                                                    +
    SSLCIPH(RC4_MD5_US)                                                +
    TRPTYPE(TCP) CONNAME('zosd.fb(1414)')                              
/*                                                                     
//MAKECCDT DD *                             
DISPLAY CHANNEL(*) ALL TYPE(CLNTCONN)       
/*                                          
//CLCHL    DD PATH='/u/dvfjs/clchl_mqd1.tab',
//            PATHOPTS=(OWRONLY,OCREAT,OTRUNC
//            PATHMODE=(SIRUSR,SIWUSR),     
//            FILEDATA=BINARY               
//

 

File /u/dvfjs/clchl_mqd1.tab is copied to the client machine and is referenced with the following data in mqclient.ini:

 

# start of mqclient.ini

Channels:
   ChannelDefinitionDirectory=c:\mqm         
   ChannelDefinitionFile=clchl_mqd1.tab      

SSL:
   SSLKeyRepository=c:\mqm\fjs4
   SSLKeyResetCount=1048576                  
   SSLHTTPProxyName=data-httpfilter.fb(8080) 
   OCSPAuthentication=WARN                   

# end of mqclient.ini

 

Tests were done using the AMQSPUT0 sample application.

 

Test 1: Specify MQName MQD1

 

C:\mqm>amqsputc Q1 MQD1
Sample AMQSPUT0 start
target queue is Q1
test

Sample AMQSPUT0 end

 

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel DEFAULT started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel DEFAULT no longer active connection 10.100.5.50

 

Notes: We connected to the MQD1 manager on channel "DEFAULT", as expected.
--------------------------------------------------------------------------------

Test 2: Specify MQName *MQD1

 

C:\mqm>amqsputc Q1 *MQD1
Sample AMQSPUT0 start
target queue is Q1
test

Sample AMQSPUT0 end

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel DEFAULT started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel DEFAULT no longer active connection 10.100.5.50

 

Notes: Same as test 1.
--------------------------------------------------------------------------------

Test 3: Specify MQName MQD1SSL to (attempt to) connect using channel SSL.

 

C:\mqm>amqsputc Q1 MQD1SSL
Sample AMQSPUT0 start
MQCONNX ended with reason code 2058

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel SSL started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel SSL no longer active connection 10.100.5.50

 

Notes: Because we connected to the queue manager named MQD1 but we requested a queue manager named MQD1SSL the client terminated with reason code 2058.
--------------------------------------------------------------------------------

Test 4: Specify MQName *MQD1SSL to (successfully) connect using channel SSL.

 

C:\mqm>amqsputc Q1 *MQD1SSL
Sample AMQSPUT0 start
target queue is Q1
test

Sample AMQSPUT0 end

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel SSL started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel SSL no longer active connection 10.100.5.50

 

Notes: Because we connected to '*MQD1SSL' instead of just 'MQD1SSL' the client ignored the fact that the queue manager that was connected to did not have the same name as the queue manager requested.
--------------------------------------------------------------------------------

Test 5: Specify MQName *MQD1RT to connect using channel PRMRT.


C:\mqm>amqsputc Q1 *MQD1RT
Sample AMQSPUT0 start
target queue is Q1

Sample AMQSPUT0 end

Server log results:
+CSQX500I :MQD1 CSQXRESP Channel PRMRT started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel PRMRT no longer active connection 10.100.5.50

 

Notes: Just another example of using the asterisk to get around the QMNAME mismatch issue.
--------------------------------------------------------------------------------

Test 6: Specify MQName *MQD1NRT to connect using channel PRMNRT.

 

C:\mqm>amqsputc Q1 *MQD1NRT
Sample AMQSPUT0 start
target queue is Q1
haha

Sample AMQSPUT0 end

+CSQX500I :MQD1 CSQXRESP Channel PRMNRT started connection 10.100.5.50
+CSQX501I :MQD1 CSQXRESP Channel PRMNRT no longer active connection 10.100.5.50

 

Notes: Final another example of using the asterisk to get around the QMNAME mismatch issue.
--------------------------------------------------------------------------------

In the end it seems to me that MQ should support something a bit (!!) more straight forward to accomplish this.  But it does work.  So yay!  I'm thinking of what should go in an RFE to enhance this so its simpler (and more obvious) how a particular channel can be selected by a client.

 

Thanks to Paul and others who gave their input on this issue.  I hope I've given enough detail (too much?) so that others with this issue can resolve it.

 

Frank Swarbrick

Mainframe Applications Development Architect

FirstBank - Lakewood, CO  USA

 

From: Dave Corbett <DAVID.CORBETT <at> USBANK.COM>
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Sent: Tuesday, November 18, 2014 1:08 PM
Subject: Re: selecting channel from CCDT

 

Frank,

You are getting to one of the reasons I do not like channel tables at all.  I have many application servers in my environment.  Each of those app servers can host many different applications (an app server!).  I want each of the applications to use a unique channel name so that I can identify them at the QMGR when I look at all of the SVRCONN connections I have.  Each application is deployed on multiple servers, so for channel tables to work, I would have to provide a unique channel table for each application that only has their channel name in it, an administrative nightmare with just that, and then I would need to have their unique channel table deployed to multiple servers.  And then, when I have a farm of MQ servers (each with a uniquely defined QMGR name) that are clones of each other, and I want the connections to be sprayed across each of them somewhat evenly, I need to use the CLNTWGHT parameter - but each channel will stand on its own because it has its own channel table and therefore cannot be balanced based on the number of connections used by the other apps connecting to that MQ server (I know - if each table has CLNTWGHT set to the same value, then each client should theoretically be balanced, and therefore the total server conns would be balanced).  But there are other issues involved as well.  These apps are typically JMS based request / reply driven and need to get their particular response from the same QMGR they sent their request to.  However, the app server's implementation of JMS uses a unique connection for both the request / response and therefore need to be pointed to the same place.  I cannot do that with channel tables and CLNTWGHT parameters.  My particular situation is a "farm" of MQ servers that front end a mainframe.

I had to go down a different load balancing path - F5 - which creates its own unique set of issues, but I find those more palatable than the generation and distribution of client channel tables.

Thanks,
David Corbett
Work:  612-973-7086
Pager: 612-280-6307
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0




From:        Frank Swarbrick <00000006cad63953-dmarc-request <at> LISTSERV.MEDUNIWIEN.AC.AT>
To:        MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT,
Date:        11/18/2014 12:46 PM
Subject:        Re: selecting channel from CCDT
Sent by:        MQSeries List <MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT>




That is indeed the behavior I am seeing.  Maybe I am simply not understanding.  Do all the clients that look at the same CCDT file use the same channel?  What is the point of having multiple client channel definitions (pointing to the same QMGR) if you cannot (apparently) use them?  I guess maybe I'm not understanding how channels are to be used.  The way it's been set up (not by me) is that each client uses a different channel.  I'm not sure why it was set up that way.  It could be that person understood it about as well as I (i.e.: not very well).

We are brand new to MQ so perhaps we've not yet obtained the knowledge we need.

From: Paul Clarke <paul.clarke85 <at> BTINTERNET.COM>
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Sent: Tuesday, November 18, 2014 11:22 AM
Subject: Re: selecting channel from CCDT


Frank,
 
What behaviour were you looking for? By default MQ will select the first channel, alphabetically, that has a QMNAME value equal to the value specified on the connection.
 
However, if you want to spread your connections across multiple channels then you should also play with the CLNTWGHT parameter. Since yours all appear to be 0 you get the ordered behaviour already mentioned. However, if you set them all to, say, 10, then you will get a spread across all the channels if this CCDT is used by multiple clients. If you want a spread even for the same client (which is generally unusual) then you need to also set AFFINITY(NONE).
 
These are, naturally, all described in greater detail in the manual.
 
Cheers,
Paul.

 
Paul Clarke

MQGem Software Limited
IBM Business Partner
www.mqgem.com
 


From: Frank Swarbrick
Sent: Tuesday, November 18, 2014 5:56 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: selecting channel from CCDT
 
I must be missing something very obvious, but I can't figure out how a client can selects a particular channel from a CCDT.  It always appears to simple select the first channel that it finds in the CCDT file.
 
Specifically, here is the results of displaying the channels using the mqsc utility:
 
C:\mqm>mqsc -n -t c:\mqm\clchl_mqd1.tab
>dis channel(*)
AMQ8414: Display Channel details.
CHANNEL(FJS.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        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(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(FS2.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )          SHARECNV(10)        CLNTWGHT(0)
AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(MQD1.2D_AS02.PRMNRT)            CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(PRM)        CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )         USERID( )
PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )         SENDDATA( )
RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)                  SHARECNV(10)
CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(SSL.CLIENTS)                    CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)
LOCLADDR(10.100.5.50)                   USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )
SCYDATA( )          SENDEXIT( )         SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)

 
 
It's always connecting me using the channel named FJS.EXPLORER.SVRCONN.
 
I'm using the following mqclient.ini file:
 
ClientExitPath:
  ExitsDefaultPath=C:\Program Files (x86)\IBM\WebSphere MQ\exits
  ExitsDefaultPath64=C:\Program Files (x86)\IBM\WebSphere MQ\exits64

Channels:
  ChannelDefinitionDirectory=c:\mqm          
  ChannelDefinitionFile=clchl_mqd1.tab      

SSL:
  SSLKeyRepository=c:\mqm\fjs4
  SSLHTTPProxyName=data-httpfilter.fb(8080)  
  SSLKeyResetCount=1048576                  
  OCSPAuthentication=WARN                    

 
What am I missing?

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com




List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com



U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.

 



---------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Re: selecting channel from CCDT

The app can use the MQCONNX call, and populate the MQCNO structure itself, probably from an externalized ini file they maintain that holds all the values.

 

http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.ref.dev.doc/q095410_.htm

 

 

 

Peter Potkay

 

 

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Frank Swarbrick
Sent: Tuesday, November 18, 2014 3:43 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: selecting channel from CCDT

 

Nightmare!

:-)

 

The only reason I am using a CCDT at all is for SSL support for a non-Java application.  Do I have another alternative?  I could not find one.

 

Frank

From: Dave Corbett <DAVID.CORBETT <at> USBANK.COM>
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Sent: Tuesday, November 18, 2014 1:08 PM
Subject: Re: selecting channel from CCDT

 

Frank,

You are getting to one of the reasons I do not like channel tables at all.  I have many application servers in my environment.  Each of those app servers can host many different applications (an app server!).  I want each of the applications to use a unique channel name so that I can identify them at the QMGR when I look at all of the SVRCONN connections I have.  Each application is deployed on multiple servers, so for channel tables to work, I would have to provide a unique channel table for each application that only has their channel name in it, an administrative nightmare with just that, and then I would need to have their unique channel table deployed to multiple servers.  And then, when I have a farm of MQ servers (each with a uniquely defined QMGR name) that are clones of each other, and I want the connections to be sprayed across each of them somewhat evenly, I need to use the CLNTWGHT parameter - but each channel will stand on its own because it has its own channel table and therefore cannot be balanced based on the number of connections used by the other apps connecting to that MQ server (I know - if each table has CLNTWGHT set to the same value, then each client should theoretically be balanced, and therefore the total server conns would be balanced).  But there are other issues involved as well.  These apps are typically JMS based request / reply driven and need to get their particular response from the same QMGR they sent their request to.  However, the app server's implementation of JMS uses a unique connection for both the request / response and therefore need to be pointed to the same place.  I cannot do that with channel tables and CLNTWGHT parameters.  My particular situation is a "farm" of MQ servers that front end a mainframe.

I had to go down a different load balancing path - F5 - which creates its own unique set of issues, but I find those more palatable than the generation and distribution of client channel tables.

Thanks,
David Corbett
Work:  612-973-7086
Pager: 612-280-6307
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0




From:        Frank Swarbrick <00000006cad63953-dmarc-request <at> LISTSERV.MEDUNIWIEN.AC.AT>
To:        MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT,
Date:        11/18/2014 12:46 PM
Subject:        Re: selecting channel from CCDT
Sent by:        MQSeries List <MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT>




That is indeed the behavior I am seeing.  Maybe I am simply not understanding.  Do all the clients that look at the same CCDT file use the same channel?  What is the point of having multiple client channel definitions (pointing to the same QMGR) if you cannot (apparently) use them?  I guess maybe I'm not understanding how channels are to be used.  The way it's been set up (not by me) is that each client uses a different channel.  I'm not sure why it was set up that way.  It could be that person understood it about as well as I (i.e.: not very well).

We are brand new to MQ so perhaps we've not yet obtained the knowledge we need.

From: Paul Clarke <paul.clarke85 <at> BTINTERNET.COM>
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Sent: Tuesday, November 18, 2014 11:22 AM
Subject: Re: selecting channel from CCDT


Frank,
 
What behaviour were you looking for? By default MQ will select the first channel, alphabetically, that has a QMNAME value equal to the value specified on the connection.
 
However, if you want to spread your connections across multiple channels then you should also play with the CLNTWGHT parameter. Since yours all appear to be 0 you get the ordered behaviour already mentioned. However, if you set them all to, say, 10, then you will get a spread across all the channels if this CCDT is used by multiple clients. If you want a spread even for the same client (which is generally unusual) then you need to also set AFFINITY(NONE).
 
These are, naturally, all described in greater detail in the manual.
 
Cheers,
Paul.

 
Paul Clarke

MQGem Software Limited
IBM Business Partner
www.mqgem.com
 


From: Frank Swarbrick
Sent: Tuesday, November 18, 2014 5:56 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: selecting channel from CCDT
 
I must be missing something very obvious, but I can't figure out how a client can selects a particular channel from a CCDT.  It always appears to simple select the first channel that it finds in the CCDT file.
 
Specifically, here is the results of displaying the channels using the mqsc utility:
 
C:\mqm>mqsc -n -t c:\mqm\clchl_mqd1.tab
>dis channel(*)
AMQ8414: Display Channel details.
CHANNEL(FJS.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        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(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(FS2.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )          SHARECNV(10)        CLNTWGHT(0)
AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(MQD1.2D_AS02.PRMNRT)            CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(PRM)        CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )         USERID( )
PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )         SENDDATA( )
RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)                  SHARECNV(10)
CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(SSL.CLIENTS)                    CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)
LOCLADDR(10.100.5.50)                   USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )
SCYDATA( )          SENDEXIT( )         SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)

 
 
It's always connecting me using the channel named FJS.EXPLORER.SVRCONN.
 
I'm using the following mqclient.ini file:
 
ClientExitPath:
  ExitsDefaultPath=C:\Program Files (x86)\IBM\WebSphere MQ\exits
  ExitsDefaultPath64=C:\Program Files (x86)\IBM\WebSphere MQ\exits64

Channels:
  ChannelDefinitionDirectory=c:\mqm          
  ChannelDefinitionFile=clchl_mqd1.tab      

SSL:
  SSLKeyRepository=c:\mqm\fjs4
  SSLHTTPProxyName=data-httpfilter.fb(8080)  
  SSLKeyResetCount=1048576                  
  OCSPAuthentication=WARN                    

 
What am I missing?

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com




List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com



U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.

 



---------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Dave Corbett | 18 Nov 21:08 2014

Re: selecting channel from CCDT

Frank,

You are getting to one of the reasons I do not like channel tables at all.  I have many application servers in my environment.  Each of those app servers can host many different applications (an app server!).  I want each of the applications to use a unique channel name so that I can identify them at the QMGR when I look at all of the SVRCONN connections I have.  Each application is deployed on multiple servers, so for channel tables to work, I would have to provide a unique channel table for each application that only has their channel name in it, an administrative nightmare with just that, and then I would need to have their unique channel table deployed to multiple servers.  And then, when I have a farm of MQ servers (each with a uniquely defined QMGR name) that are clones of each other, and I want the connections to be sprayed across each of them somewhat evenly, I need to use the CLNTWGHT parameter - but each channel will stand on its own because it has its own channel table and therefore cannot be balanced based on the number of connections used by the other apps connecting to that MQ server (I know - if each table has CLNTWGHT set to the same value, then each client should theoretically be balanced, and therefore the total server conns would be balanced).  But there are other issues involved as well.  These apps are typically JMS based request / reply driven and need to get their particular response from the same QMGR they sent their request to.  However, the app server's implementation of JMS uses a unique connection for both the request / response and therefore need to be pointed to the same place.  I cannot do that with channel tables and CLNTWGHT parameters.  My particular situation is a "farm" of MQ servers that front end a mainframe.

I had to go down a different load balancing path - F5 - which creates its own unique set of issues, but I find those more palatable than the generation and distribution of client channel tables.

Thanks,
David Corbett
Work:  612-973-7086
Pager: 612-280-6307
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0



From:        Frank Swarbrick <00000006cad63953-dmarc-request-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org>
To:        MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org,
Date:        11/18/2014 12:46 PM
Subject:        Re: selecting channel from CCDT
Sent by:        MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org>



That is indeed the behavior I am seeing.  Maybe I am simply not understanding.  Do all the clients that look at the same CCDT file use the same channel?  What is the point of having multiple client channel definitions (pointing to the same QMGR) if you cannot (apparently) use them?  I guess maybe I'm not understanding how channels are to be used.  The way it's been set up (not by me) is that each client uses a different channel.  I'm not sure why it was set up that way.  It could be that person understood it about as well as I (i.e.: not very well).

We are brand new to MQ so perhaps we've not yet obtained the knowledge we need.

From: Paul Clarke <paul.clarke85-C2P5NI4ZpDVm9/pnFjKg3w@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org
Sent: Tuesday, November 18, 2014 11:22 AM
Subject: Re: selecting channel from CCDT

Frank,
 
What behaviour were you looking for? By default MQ will select the first channel, alphabetically, that has a QMNAME value equal to the value specified on the connection.
 
However, if you want to spread your connections across multiple channels then you should also play with the CLNTWGHT parameter. Since yours all appear to be 0 you get the ordered behaviour already mentioned. However, if you set them all to, say, 10, then you will get a spread across all the channels if this CCDT is used by multiple clients. If you want a spread even for the same client (which is generally unusual) then you need to also set AFFINITY(NONE).
 
These are, naturally, all described in greater detail in the manual.
 
Cheers,
Paul.
 
Paul Clarke

MQGem Software Limited
IBM Business Partner
www.mqgem.com
 


From: Frank Swarbrick
Sent: Tuesday, November 18, 2014 5:56 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org
Subject: selecting channel from CCDT
 
I must be missing something very obvious, but I can't figure out how a client can selects a particular channel from a CCDT.  It always appears to simple select the first channel that it finds in the CCDT file.
 
Specifically, here is the results of displaying the channels using the mqsc utility:
 
C:\mqm>mqsc -n -t c:\mqm\clchl_mqd1.tab
>dis channel(*)
AMQ8414: Display Channel details.
CHANNEL(FJS.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        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(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(FS2.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )          SHARECNV(10)        CLNTWGHT(0)
AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(MQD1.2D_AS02.PRMNRT)            CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(PRM)        CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )         USERID( )
PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )         SENDDATA( )
RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)                  SHARECNV(10)
CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(SSL.CLIENTS)                    CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)
LOCLADDR(10.100.5.50)                   USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )
SCYDATA( )          SENDEXIT( )         SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
 
 
It's always connecting me using the channel named FJS.EXPLORER.SVRCONN.
 
I'm using the following mqclient.ini file:
 
ClientExitPath:
  ExitsDefaultPath=C:\Program Files (x86)\IBM\WebSphere MQ\exits
  ExitsDefaultPath64=C:\Program Files (x86)\IBM\WebSphere MQ\exits64

Channels:
  ChannelDefinitionDirectory=c:\mqm          
  ChannelDefinitionFile=clchl_mqd1.tab      

SSL:
  SSLKeyRepository=c:\mqm\fjs4
  SSLHTTPProxyName=data-httpfilter.fb(8080)  
  SSLKeyResetCount=1048576                  
  OCSPAuthentication=WARN                    
 
What am I missing?

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com




List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com



U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.

---------------------------------------------------------------------
List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Paul Clarke | 18 Nov 19:22 2014

Re: selecting channel from CCDT

Frank,
 
What behaviour were you looking for? By default MQ will select the first channel, alphabetically, that has a QMNAME value equal to the value specified on the connection.
 
However, if you want to spread your connections across multiple channels then you should also play with the CLNTWGHT parameter. Since yours all appear to be 0 you get the ordered behaviour already mentioned. However, if you set them all to, say, 10, then you will get a spread across all the channels if this CCDT is used by multiple clients. If you want a spread even for the same client (which is generally unusual) then you need to also set AFFINITY(NONE).
 
These are, naturally, all described in greater detail in the manual.
 
Cheers,
Paul.
 
Paul Clarke

MQGem Software Limited
IBM Business Partner
www.mqgem.com
 
Sent: Tuesday, November 18, 2014 5:56 PM
Subject: selecting channel from CCDT
 
I must be missing something very obvious, but I can't figure out how a client can selects a particular channel from a CCDT.  It always appears to simple select the first channel that it finds in the CCDT file.
 
Specifically, here is the results of displaying the channels using the mqsc utility:
 
C:\mqm>mqsc -n -t c:\mqm\clchl_mqd1.tab
>dis channel(*)
AMQ8414: Display Channel details.
CHANNEL(FJS.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        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(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(FS2.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )          SHARECNV(10)        CLNTWGHT(0)
AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(MQD1.2D_AS02.PRMNRT)            CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(PRM)        CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )         USERID( )
PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )         SENDDATA( )
RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)                  SHARECNV(10)
CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(SSL.CLIENTS)                    CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)
LOCLADDR(10.100.5.50)                   USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )
SCYDATA( )          SENDEXIT( )         SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
 
 
It's always connecting me using the channel named FJS.EXPLORER.SVRCONN.
 
I'm using the following mqclient.ini file:
 
ClientExitPath:
   ExitsDefaultPath=C:\Program Files (x86)\IBM\WebSphere MQ\exits
   ExitsDefaultPath64=C:\Program Files (x86)\IBM\WebSphere MQ\exits64

Channels:
   ChannelDefinitionDirectory=c:\mqm         
   ChannelDefinitionFile=clchl_mqd1.tab      

SSL:
   SSLKeyRepository=c:\mqm\fjs4
   SSLHTTPProxyName=data-httpfilter.fb(8080) 
   SSLKeyResetCount=1048576                  
   OCSPAuthentication=WARN                   
 
What am I missing?

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Barton, Linda | 18 Nov 19:09 2014
Picon

Re: selecting channel from CCDT

I believe it selects the first channel that has the qmgr you are looking for.

 

 

Linda Barton

 

 

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Frank Swarbrick
Sent: Tuesday, November 18, 2014 12:57 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: selecting channel from CCDT

 

I must be missing something very obvious, but I can't figure out how a client can selects a particular channel from a CCDT.  It always appears to simple select the first channel that it finds in the CCDT file.

 

Specifically, here is the results of displaying the channels using the mqsc utility:

 

C:\mqm>mqsc -n -t c:\mqm\clchl_mqd1.tab
>dis channel(*)
AMQ8414: Display Channel details.
CHANNEL(FJS.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        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(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(FS2.EXPLORER.SVRCONN)           CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )          SHARECNV(10)        CLNTWGHT(0)
AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(MQD1.2D_AS02.PRMNRT)            CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )
USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )
SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(PRM)        CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)        LOCLADDR( )         USERID( )
PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )          SCYDATA( )          SENDEXIT( )         SENDDATA( )
RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER(CN=service6.1stbankofcolorado.com)                  SHARECNV(10)
CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)
AMQ8414: Display Channel details.
CHANNEL(SSL.CLIENTS)                    CHLTYPE(CLNTCONN)   DESCR( )            TRPTYPE(TCP)        CONNAME(ZOSD.FB(1414))                  QMNAME(MQD1)
LOCLADDR(10.100.5.50)                   USERID( )           PASSWORD( )         MODENAME( )         TPNAME( )           MAXMSGL(104857600)  HBINT(300)          SCYEXIT( )
SCYDATA( )          SENDEXIT( )         SENDDATA( )         RCVEXIT( )          RCVDATA( )          COMPHDR(NONE)       COMPMSG(NONE)       SSLCIPH(RC4_MD5_US) SSLPEER( )
SHARECNV(10)        CLNTWGHT(0)         AFFINITY(PREFERRED) DEFRECON(NO)        ALTDATE(1969-12-31) ALTTIME(17.00.00)

 

 

It's always connecting me using the channel named FJS.EXPLORER.SVRCONN.

 

I'm using the following mqclient.ini file:

 

ClientExitPath:
   ExitsDefaultPath=C:\Program Files (x86)\IBM\WebSphere MQ\exits
   ExitsDefaultPath64=C:\Program Files (x86)\IBM\WebSphere MQ\exits64

Channels:
   ChannelDefinitionDirectory=c:\mqm         
   ChannelDefinitionFile=clchl_mqd1.tab      

SSL:
   SSLKeyRepository=c:\mqm\fjs4
   SSLHTTPProxyName=data-httpfilter.fb(8080) 
   SSLKeyResetCount=1048576                  
   OCSPAuthentication=WARN                   

 

What am I missing?

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Thomas, Don | 14 Nov 21:30 2014
Picon

Re: Mass MQ Migration

Thanks Peter. I would love to implement Paul’s wonderful tool. But alas, I’m completely on the client’s network and it is VERY locked down.

 

Q. Does my plan seem reasonable or insane?

A. Reasonable. But I never met an insane person who didn’t think they were reasonable.

And how do you see yourself?

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Friday, November 14, 2014 11:14 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Mass MQ Migration

 

Don, I’ve done similar migrations over the years.

 

Q. What is the surest way of mapping an existing cluster so that I don’t miss any components?

A. Neil gave you a good head start. Access the Full Repository to see all the QMs that are in the cluster. On each QM in the cluster, identify all cluster and cluster sender channels, and all queues that have the cluster attribute enabled. Pay attention if namelists are being used to cluster any object to multiple clusters. Look at the QM properties of every QM to make sure its not a FR. Just because FR1 says QMXYZ is a PR, doesn’t mean QMXYZ isn’t a FR for another unrelated cluster!   <:-O

 

 

Q. Have any of you been through an exercise like this?

A. yes, but relatively small clusters and never more than a couple over lapping.

 

Q. Does my plan seem reasonable or insane?

A. Reasonable. But I never met an insane person who didn’t think they were reasonable.

 

Q. Are there any suggestions that might make my job simpler?

A. Buy yourself a copy of MO71 from MQGem. With its ability to look at the same object type across multiple QMs at the same time, and the ability to export pretty much anything it shows you into spreadsheets or runmqsc commands, it makes planning for migrations and to see the status of your overall environment a lot easier.

 

 

Peter Potkay

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Thomas, Don
Sent: Friday, November 14, 2014 10:06 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Mass MQ Migration

 

Thanks Neil.

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Neil Casey
Sent: Thursday, November 13, 2014 5:36 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Mass MQ Migration

 

Hi Don,

 

I’d like to look at your first question (which is relatively easy) and maybe someone else will discuss the others.

 

Mapping a cluster isn’t too difficult.

 

1. Find any queue manager that is in the cluster

2. runmqsc: dis clusqmgr(*) conname cluster(CLUSNAME) where(qmtype eq repos)

3. If you want all clusters, change the 'cluster(CLUSNAME)' to ‘cluster’

4. Log on to the server hosting a full repository (as returned in 2 or 3)

5. runmqsc: dis clusqmgr(*) all

6. runmqsc: dis qc(*) all

 

Full repositories know everything (from the cluster perspective) about all queue managers in the cluster.

 

If the full repository is FR for more than one cluster, you can limit the output by adding ‘cluster(CLUSNAME)’ to the dis clusqmgr or dis qc commands.

 

Regards,

 

 

Neil

 

 

-- 

Neil Casey 

Senior Consultant | Syntegrity Solutions


 +61 414 615 334 neil.casey <at> syntegrity.com.au 

Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006

Analyse  >>  Integrate  >>  Secure  >>  Educate



 

 

On 14 Nov 2014, at 3:44 am, Thomas, Don <dont <at> HP.COM> wrote:

 

Listers,

                I have a project getting under way that is going to require that I migrate multiple MQ implementations to new servers in a new environment. There are multiple user groups involved and the migrations will take place in stages. The two environments will be running concurrently for a period of time. The plan is to recreate the queue managers in the new environment using different queue manager names, but consisting of basically the same objects. Of course the channel names will need to change, but the queue names will stay the same. The initial stage involves several queue managers that are members of two MQ clusters. One of the clusters is completely included in this wave but some members of the other cluster aren’t scheduled until a later date. All the queue managers in the first stage are at V7.0.1.10 and running on Solaris Sparc and z/OS.

                My plan is to create backups of the queue managers using saveqmgr. Edit the backup files and make the necessary changes for queue manager names and channel names. My thinking is to initially omit any references to the clusters when creating the new queue managers. Then after I successfully create and start the new queue managers in the new environment I will go back and recreate the cluster components as needed. My cluster experience is marginal. I’ve had simple clusters before but have not had the situation where queue managers belong to multiple clusters. I have some documentation for the environment but I don’t think it is complete.

 

                My questions to the List:

 

                What is the surest way of mapping an existing cluster so that I don’t miss any components?

                Have any of you been through an exercise like this?

                Does my plan seem reasonable or insane?

                Are there any suggestions that might make my job simpler?

 

Anything you can offer will be appreciated.

 

 

Don Thomas

 

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Coombs, Lawrence | 14 Nov 17:39 2014

Re: Reset qmgr runmqsc (repost)

Reposting because I messed up  the subject line………

 

When you issue the “reset qmgr type(statistics)”  command in runmqsc, would it be of any value to also display the enqueue/dequeue count? Just wondering if this has crossed anyone else’s mind.

 

 

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Thomas, Don | 14 Nov 16:05 2014
Picon

Re: Mass MQ Migration

Thanks Neil.

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Neil Casey
Sent: Thursday, November 13, 2014 5:36 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Mass MQ Migration

 

Hi Don,

 

I’d like to look at your first question (which is relatively easy) and maybe someone else will discuss the others.

 

Mapping a cluster isn’t too difficult.

 

1. Find any queue manager that is in the cluster

2. runmqsc: dis clusqmgr(*) conname cluster(CLUSNAME) where(qmtype eq repos)

3. If you want all clusters, change the 'cluster(CLUSNAME)' to ‘cluster’

4. Log on to the server hosting a full repository (as returned in 2 or 3)

5. runmqsc: dis clusqmgr(*) all

6. runmqsc: dis qc(*) all

 

Full repositories know everything (from the cluster perspective) about all queue managers in the cluster.

 

If the full repository is FR for more than one cluster, you can limit the output by adding ‘cluster(CLUSNAME)’ to the dis clusqmgr or dis qc commands.

 

Regards,

 

 

Neil

 

 

-- 

Neil Casey 

Senior Consultant | Syntegrity Solutions


 +61 414 615 334 neil.casey <at> syntegrity.com.au 

Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006

Analyse  >>  Integrate  >>  Secure  >>  Educate



 

 

On 14 Nov 2014, at 3:44 am, Thomas, Don <dont <at> HP.COM> wrote:

 

Listers,

                I have a project getting under way that is going to require that I migrate multiple MQ implementations to new servers in a new environment. There are multiple user groups involved and the migrations will take place in stages. The two environments will be running concurrently for a period of time. The plan is to recreate the queue managers in the new environment using different queue manager names, but consisting of basically the same objects. Of course the channel names will need to change, but the queue names will stay the same. The initial stage involves several queue managers that are members of two MQ clusters. One of the clusters is completely included in this wave but some members of the other cluster aren’t scheduled until a later date. All the queue managers in the first stage are at V7.0.1.10 and running on Solaris Sparc and z/OS.

                My plan is to create backups of the queue managers using saveqmgr. Edit the backup files and make the necessary changes for queue manager names and channel names. My thinking is to initially omit any references to the clusters when creating the new queue managers. Then after I successfully create and start the new queue managers in the new environment I will go back and recreate the cluster components as needed. My cluster experience is marginal. I’ve had simple clusters before but have not had the situation where queue managers belong to multiple clusters. I have some documentation for the environment but I don’t think it is complete.

 

                My questions to the List:

 

                What is the surest way of mapping an existing cluster so that I don’t miss any components?

                Have any of you been through an exercise like this?

                Does my plan seem reasonable or insane?

                Are there any suggestions that might make my job simpler?

 

Anything you can offer will be appreciated.

 

 

Don Thomas


 

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


Gmane