There are several important components in MQ: Queue Manager (QueueManager), queues (queue), and channel (Channel). The basic methods of operation are as follows:
Creating a Queue Manager
Crtmqm–q Qmgrname
-Q refers to creating the default queue Manager
Delete Queue Manager
DLTMQM Qmgrname
Start the Queue Manager
STRMQM Qmgrname
If you are starting the default Queue manager, you can do so without its name
Run MQSeries command
RUNMQSC Qmgrname
If this is the default queue manager, you can take it without its name
Put messages in the queue
Amqsput QName Qmgrname
If the queue is a queue in the default Queue manager, you can have a name without its queue Manager
To remove a message from the queue
Amqsget QName Qmgrname
If the queue is a queue in the default Queue manager, you can have a name without its queue Manager
Defining model Queues
DEFINE Qmodel (QNAME) Deftype (Tempdyn)
Defining a local transport queue
DEFINE qlocal (qtname) USAGE (XMITQ) defpsist (YES) +
INITQ (SYSTEM. CHANNEL. INITQ) +
PROCESS (processname) REPLACE
Creating a Process definition
DEFINE PROCESS (proname) +
Descr (' STRING ') +
Appltype (WINDOWSNT) +
Applicid (' runmqchl-c sdr_test-m qm_ TEST ')
Where the value of Appltype can be: CICS, UNIX, WINDOWS, WINDOWSNT, etc.
Create a sender Channel
DEFINE CHANNEL (sdrname) Chltype (SDR) +
CONNAME (' 100.100.100.215 (1418) ') XMITQ (qtname) REPLACE
The Chltype can be: SDR, SVR, RCVR, Rqstr, Clntconn, Svrconn, CLUSSDR and CLUSRCVR.
Clears all messages in the queue
Clear Qlocal (QNAME)
Two Configure a remote connection that can communicate
The above tells the basic command operation of MQ, but it is not practical to know it. The ultimate goal of MQ is to implement remote communications, so here's a concrete example of how to implement a remote connection. The goal of this example is to establish a pair of MQ servers that implement messaging, based on NT and UNIX platforms respectively.
First build a queue manager at NT end
Crtmqm–q qm_nt
Start the Queue Manager
STRMQM qm_nt
Running the MQ console command
RUNMQSC qm_nt
Create a dead-letter queue
DEFINE QL (NT. DEADQ) defpsist (YES) REPLACE
Change the Queue Manager properties and set their dead-letter queues
ALTER QMGR DEADQ (NT. DEADQ)
Creating a Process definition
DEFINE PROCESS (P_NT) +
Appltype (WINDOWSNT) +
Applicid (' runmqchl-c sdr_nt-m qm_nt ')
To create a local transport queue
DEFINE QL (QT_NT) USAGE (XMITQ) defpsist (YES) +
INITQ (SYSTEM. CHANNEL. INITQ) +
PROCESS (P_NT) REPLACE
Create a remote queue definition that corresponds to the local queue Q_unix on the UNIX machine, and the transport queue is qt_nt
DEFINE Qremote (QR_NT) +
Rname (Q_unix) rqmname (Qm_unix) +
XMITQ (QT_NT)
Creates a sender channel with a transport queue of QT_NT, a remote host address of 10.10.10 2, and a listening port of 1414
DEFINE CHANNEL (SDR_NT) Chltype (SDR) +
CONNAME (' 10.10.10.2 (1414) ') XMITQ (QT_NT) REPLACE
Creating a server Connection Channel
DEFINE CHANNEL (S_NT) chltype (svrconn) REPLACE
Creating a Queue Manager on the UNIX side
Crtmqm–q Qm_unix
Start the Queue Manager
STRMQM Qm_unix
Add Listener
To modify the/etc/services file, add a line:
MQSeries 1414/tcp #MQSeries Channel Listener
Modify the/etc/inetd.conf file to join a line (start the listener)
MQSeries Stream TCP nowait mqm/usr/lpp/mqm/bin/amqcrsta amqcrsta–m Qm_unix
Run the following command to make the modification work
Refresh–s inetd
Running the MQ console command
RUNMQSC Qm_unix
Create a dead-letter queue
DEFINE QL (UNIX. DEADQ) defpsist (YES) REPLACE
Change the Queue Manager properties and set their dead-letter queues
ALTER QMGR DEADQ (UNIX. DEADQ)
Create a receiver channel whose name must be the same as the remote sender
DEFINE CHANNEL (SDR_NT) chltype (RCVR) REPLACE
Create a local queue
DEFINE QL (Q_unix) defpsist (YES) REPLACE
Creating a server Connection Channel
DEFINE CHANNEL (S_unix) chltype (svrconn) REPLACE
After that, the configuration of the remote connection is complete. Next you need to verify that the configuration is correct.
Start the sender channel on the NT side
Runmqchl–c sdr_nt–m qm_nt or start CHL (SDR_NT)
Sending messages from NT end to UNIX side
Amqsput qr_nt Qm_nt
Receiving messages on the UNIX side
/usr/mqm/samp/bin/amqsget Q_unix Qm_unix
If you receive a message, the configuration is successful.
In addition, the listener is automatically established in NT under normal circumstances when the Queue Manager is established, and the listener is automatically started when the queue Manager is started. You can, of course, configure the listener manually.
To modify the/winnt/system32/drivers/etc/services file, add a line to the file:
MQSeries 1414/tcp #MQSeries Channel Listener
Start listener
Runmqlsr–t tcp–p 1414–m Qm_nt
The above shows how to establish a simple one-way transmission network. Messages are routed from the NT side to the UNIX side. Setting up a remote connection from UNIX to NT end is similar to the above, and it is equally true to establish a two-way transmission network.
Three Configuring JNDI
JNDI is often used to implement message sending and receiving in JMS. Because JNDI this way is more flexible, for programming is also relatively simple.
After installing the MQSeries Client for Java, locate the Jmsadmin.config file in the/java/bin directory. This file is mainly used to explain the storage mode and storage address of the context, corresponding to the two parameters in the file Initial_context_factory and Provider_url. The typical Jmsadmin.config file reads as follows:
Initial_context_factory represents the service provider used by Jmsadmin Tool. There are currently three supported values. Com.sun.jndi.ldap.LdapCtxFactory is used for LDAP, and you must install an LDAP server if you use it. Com.sun.jndi.fscontext.RefFSContextFactory is used in the file system context, which requires only the user to provide a file path to hold the context. Com.ibm.ejs.ns.jndi.CNInitialContextFactory is specifically for WebSphere, and it needs to be used in conjunction with the Cosnaming repository of WebSphere.
Provider_url represents the URL of the session's initial context, the root of all JNDI operations implemented by Jmsadmin tool. It corresponds to the initial_context_factory one by one.
Ldap://hostname/contextname for LDAP
File:[drive:]/pathname for file System context
iiop://hostname[:p ort]/[? TARGETCONTEXT=CTX] used to access the WebSphere cosnaming namespace
Finally, there is a parameter security_authentication that indicates whether JNDI has passed security credentials to the service provider you are using. Use this parameter only if you are using the LDAP service provider. This parameter has three values, none (anonymous authentication), simple (easy authentication), and CRAM-MD5 authentication mechanism. If no valid value is supplied, the default is None.
After confirming the configuration file, you can start the Jmsadmin console in the/java/bin directory. You can also use the following command to start the console in any directory:
Jmsadmin–cfg Mq_java_install_path/java/bin/jmsadmin.config
Where Mq_java_install_path is the root directory of the MQSeries Client for JAVA installation.
If the startup fails, check to see if your environment variables are set correctly. According to my personal experience, in addition to adding Com.ibm.mq.jar and Com.ibm.mqjms.jar to environment variables, add Fscontext.jar and Providerutil.jar to the environment variables.
When you enter the Jmsadmin console, you are free to define sub context. For the operation of a child context, there are mainly commands:
Display CTX
Define CTX (Ctxname)
Change CTX (Ctxname)
Change CTX (=up)
Change CTX (=init)
Delete CTX (ctxname)
Of course, the main task here is not to define the sub context, but to define the following objects:
Mqqueueconnectionfactory
Mqtopicconnectionfactory
Mqqueue
Mqtopic
(There are other objects, such as mqxaqueueconnectionfactory, etc., not commonly used, this does not explain.) ）
You can use many verbs to manipulate managed objects in the directory namespace. ALTER, DEFINE, DISPLAY, DELETE, COPY, and move are all relatively simple to use, and here are just one or two for illustration.
Example one: Define a queueconnectionfactory, connect the host 10.10.10.18, Port 1414
DEFINE QCF (EXAMPLEQCF) +
DESC (Example Queue Connection Factory) +
TRAN (CLIENT) +
HOST (10.10.10.18) +
QMGR (qm_example) +
CHAN (s_example) +
PORT (1414) +
CCSID (1381)
Example two: Define a Queue that corresponds to the q_example in MQ
DEFINE Q (EXAMPLEQL) +
DESC (local queue) +
QMGR (qm_example) +
QUEUE (q_example) +
CCSID (1381)
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
