trindade.myphotos.cc
Open in
urlscan Pro
79.169.200.218
Public Scan
URL:
https://trindade.myphotos.cc/lazysysadmin/2019/04/14/ibm-mq-basics-remote-queues-and-channels/
Submission: On December 28 via manual from AE — Scanned from PT
Submission: On December 28 via manual from AE — Scanned from PT
Form analysis
2 forms found in the DOM<form id="commentform" class="comment-form">
<iframe title="Comment Form"
src="https://jetpack.wordpress.com/jetpack-comment/?blogid=155648049&postid=103&comment_registration=0&require_name_email=1&stc_enabled=1&stb_enabled=1&show_avatars=1&avatar_default=mystery&greeting=Leave+a+Reply&jetpack_comments_nonce=386eb2c79a&greeting_reply=Leave+a+Reply+to+%25s&color_scheme=light&lang=en_US&jetpack_version=12.6.1&show_cookie_consent=10&has_cookie_consent=0&token_key=%3Bnormal%3B&sig=218644b6d5dd0e7a35951ba9a6dcfc5839ac1125#parent=https%3A%2F%2Ftrindade.myphotos.cc%2Flazysysadmin%2F2019%2F04%2F14%2Fibm-mq-basics-remote-queues-and-channels%2F"
name="jetpack_remote_comment" style="width: 100%; height: 2px; border: 0px;" class="jetpack_remote_comment" id="jetpack_remote_comment" sandbox="allow-same-origin allow-top-navigation allow-scripts allow-forms allow-popups" scrolling="no">
</iframe>
<!--[if !IE]><!-->
<script>
document.addEventListener('DOMContentLoaded', function() {
var commentForms = document.getElementsByClassName('jetpack_remote_comment');
for (var i = 0; i < commentForms.length; i++) {
commentForms[i].allowTransparency = false;
commentForms[i].scrolling = 'no';
}
});
</script>
<!--<![endif]-->
</form>
GET https://trindade.myphotos.cc/lazysysadmin/
<form role="search" method="get" id="searchform" class="searchform" action="https://trindade.myphotos.cc/lazysysadmin/">
<div>
<label class="screen-reader-text" for="s">Search for:</label>
<input type="text" value="" name="s" id="s">
<input type="submit" id="searchsubmit" value="Search">
</div>
</form>
Text Content
Lazy SysAdmin Articles for Lazy Systems Administrators Skip to content * Home ← IBM MQ basics: the first queue IBM MQ basics: publish and subscribe → IBM MQ BASICS: REMOTE QUEUES AND CHANNELS Posted on April 14, 2019 by António Trindade In the first installment of the IBM MQ Basics, available here, I showed you basic queue creation and usage. If IBM MQ would only allow local queues to be created and used, it would be less useful. One of the strengths of IBM MQ is the ability to link two or more queue managers and send messages to another queue manager. In this article, I’m going to show you how to link two queue managers using a remote queues and channels. First of all, you need two different queue managers. It doesn’t matter if they are in the same machine. I’m using two machines (actually, two virtual machines in my work machine, but the end result is absolutely the same). I’m using the same queue manager that I configured in the last article of this series and another one, named QM2, with the same configuration, that is, a listener named LISTENER.TCP, with transport type (TRPTYPE) TCP, listenening on port 1414 and a channel for administration purposes of type server connection (SVRCONN) name CLNT.ADM. REMOTE QUEUES A remote queue is a queue like any other, with a few notable exceptions: * it is impossible to read from; it can only be written to; * it refers to another queue (remote, local, or alias) in another queue manager; * it does not occupy any hard disk space, except for the space needed to store its definition; * you can (and should) specify a transmission queue (more on this type of queue later); CHANNELS AND CHANNEL TYPES Communication between queue managers and between clients and queue managers is always done using channels. Channels’ names can be at most 21 characters long. We’ve already talked about one type of channel (the SVRCONN type). The server-connection channel is used for communicating between MQ client applications and a queue manager. The other two types of channels I am going to talk about now are the sender channel (SDR) and receiver channel (RCVR) types. As their name implies, the receiver channel is used as the receiving end of a sender channel. So, they always come in pairs. The sender and receiver channels must have the same name. That’s how a sending queue manager identifies the receiving end. TRANSMISSION QUEUES Finally, one must define a transmission queue before creating a sender channel. This is a special type of local queue (you can write to and read from it, although it is not advisable) that serves as a temporary message store for messages being sent to a remote queue manager. If, for example, the remote queue manager is down for some reason or the network connection between the two queue managers is not available, the sending queue manager stores the messages destined to the remote one in this type of queue. For each sender channel you need create a transmission queue. PUTTING IT ALL TOGETHER CONFIGURING QM1 Ok. Let ‘s start. In the following example, I’m going to create a remote queue in the QM1 queue manager that refers to a local queue in the QM2 queue manager. Beginning with the QM1 queue manager. First, create a transmission queue: DEFINE QLOCAL(‘TO.QM2.X’) USAGE(XMITQ) TRIGGER TRIGDATA(TO.QM2) TRIGTYPE(FIRST) This command defines something not discussed above: triggering. For now, let me just say that the last three options enables auto starting the channel named TO.QM2 when a message is placed in the TO.QM2.XmitQ transmission queue. Next, we need to create a sender channel: DEFINE CHANNEL(TO.QM2) CHLTYPE(SDR) CONNAME(‘mq2(1414)’) XMITQ(‘TO.QM2.X’) This command defines a sender channel named TO.QM2 to host mq2, TCP port 1414 that uses the TO.QM2.XmitQ transmission queue. Finally, to wrap the configurations in the QM1 queue manager, define the Q2.W remote queue: DEFINE QREMOTE(Q2.W) RQMNAME(QM2) RNAME(Q2.R) XMITQ(‘TO.QM2.X’) This remote queue definition has a configuration option which is not widely used: the option XMITQ. This option allows you to choose the sender channel which will be used by this remote queue by specifying its transmission queue. If you do not specify the transmission queue used by a remote one, the queue manager will choose an appropriate channel to send your messages through. CONFIGURING QM2 The configuration for the QM2 queue manager is very simple. First, define a local queue with the name of the RNAME option of the remote queue you created in QM1 (Q2.R). DEFINE QLOCAL(Q2.R) Finally, define a receiver channel with the same name of the sender channel defined in the QM1 queue manager. DEFINE CHANNEL(TO.QM2) CHLTYPE(RCVR) TESTING In the mq1 machine run the following command ~$ /opt/mqm/samp/bin/amqsput Q2.W QM1 Sample AMQSPUT0 start target queue is Q2.W Hello, World! end End of messages Sample AMQSPUT0 end And, in the mq2 machine: ~$ /opt/mqm/samp/bin/amqsget Q2.R QM2 Sample AMQSGET0 start message <Hello, World!> message <end> message <End of messages> ^C That’s a wrap. Stay tuned. In the next post, I’ll be talking about the publish/subscribe feature. IBM MQ BASICS: THE FIRST QUEUE Now that we've installed MQ, it's time to try it out. If you haven't read it, you can go to Installing IBM MQ on Linux to learn how to do it. In this article, I'll show you the basics of IBM MQ and what it can do for your applications'… March 5, 2019 In "Middleware" IBM MQ BASICS: PUBLISH AND SUBSCRIBE In the first three articles of this series, I introduced you to IBM MQ and its basic functionalities (queues, local and remote, channels and listeners). This time, I'll start complicating things a bit. This time I'll write about the publish and subscribe feature of IBM MQ. Overview Suppose you have… July 12, 2019 With 1 comment BASIC MQ COMMANDS This should probably be my first blog post about MQ, but I confess: I was too excited to start writing. Lately I've had little time to post new stuff. This is probably just an excuse to write something again. In the following lines, I'll give you an introduction to the… November 28, 2021 In "Basics" This entry was posted in MQ and tagged ibm mq, IBMMQ, middleware, mq, mqseries, websphere mq, WebSphereMQ. Bookmark the permalink. ← IBM MQ basics: the first queue IBM MQ basics: publish and subscribe → ONE RESPONSE TO IBM MQ BASICS: REMOTE QUEUES AND CHANNELS 1. Pingback: MQGem Monthly (May 2019) | MQGem Software LEAVE A REPLYCANCEL REPLY * Search for: * RECENT POSTS * Basic MQ commands * IBM MQ basics: security — part 2: user authentication * IBM MQ basics: security — part 3: object permissions * IBM MQ basics: security — part 1: SSL communications * IBM MQ basics: publish and subscribe * RECENT COMMENTS * MQGem Monthly (December 2021) | MQGem Software on Basic MQ commands * António Trindade on IBM MQ installation in Linux * thanith on IBM MQ installation in Linux * MQGem Monthly (July 2019) | MQGem Software on IBM MQ basics: publish and subscribe * MQGem Monthly (May 2019) | MQGem Software on IBM MQ basics: remote queues and channels * ARCHIVES * November 2021 * August 2020 * August 2019 * July 2019 * April 2019 * March 2019 * February 2019 * December 2018 * CATEGORIES * Basics * General * Middleware * MQ * Security * Uncategorized * LINKS * Colin Paice — MQ Blog * MQGem Homepage * MQGem Blog * META * Log in * Entries feed * Comments feed * WordPress.org Lazy SysAdmin Proudly powered by WordPress.