Sample scenarios to show Pub/Sub of Clustered Topics in MQ V7

White paper


Abstract

The purpose of this techdoc is to provide some sample scenarios for using a topic in a cluster and to perform publish and subscribe (Pub/Sub) operations on that topic, from the local queue manager and the remote queue managers.

Content

This technote contains the following sections:





Testcase configuration details

The scenarios described here use 3 Queue Managers in an MQ cluster:

Cluster Name: NEWCLUSTER
QM1 - full repository
QM2 - full repository
QM3 - partial repository

Clustered Topic Object:
Name: TESTTOPIC
Topic String: PUBSUBV7
Local to QMgr: QM1

The following 2 commands will create the above clustered topic:

runmqsc QM1
define topic(TESTTOPIC) topicstr(PUBSUBV7) cluster(NEWCLUSTER)

The definition of the clustered topic will be pushed (fanned out) to all the Queue Managers in the cluster.
In contrast, the definition of a clustered queue is ONLY provided to the queue manager that is asking for it.

In QM1 (where the topic is local) the display of the topic shows:

display topic(TESTTOPIC)
     2 : display topic(TESTTOPIC)
AMQ8633: Display topic details.
   TOPIC(TESTTOPIC)                        TYPE(LOCAL)
   TOPICSTR(PUBSUBV7)                      DESCR( )
   CLUSTER(NEWCLUSTER)                     DURSUB(ASPARENT)
   PUB(ASPARENT)                           SUB(ASPARENT)
   DEFPSIST(ASPARENT)                      DEFPRTY(ASPARENT)
   DEFPRESP(ASPARENT)                      ALTDATE(2009-06-26)
   ALTTIME(13.54.04)                       PMSGDLV(ASPARENT)
   NPMSGDLV(ASPARENT)                      PUBSCOPE(ASPARENT)
   SUBSCOPE(ASPARENT)                      PROXYSUB(FIRSTUSE)
   WILDCARD(PASSTHRU)                      MDURMDL( )
   MNDURMDL( )

In QM2 (where the topic is NOT local) the display of the topic shows:

display topic(TESTTOPIC)
     1 : display topic(TESTTOPIC)
AMQ8147: WebSphere MQ object TESTTOPIC not found.

In QM2, we need to provide an additional qualifier: TYPE(CLUSTER), as follows:

display topic(TESTTOPIC) TYPE(CLUSTER)
     2 : display topic(TESTTOPIC) TYPE(CLUSTER)  
AMQ8633: Display topic details.
   TOPIC(TESTTOPIC)                        TYPE(CLUSTER)
   TOPICSTR(PUBSUBV7)                      DESCR( )
   CLUSTER(NEWCLUSTER)                     CLUSQMGR(QM_ANGELILLO)
   QMID(QM_ANGELILLO_2008-06-16_14.26.07)
   DURSUB(ASPARENT)                        PUB(ASPARENT)
   SUB(ASPARENT)                           DEFPSIST(ASPARENT)
   DEFPRTY(ASPARENT)                       DEFPRESP(ASPARENT)
   CLUSDATE(2009-06-26)                    CLUSTIME(13.54.04)
   ALTDATE(2009-06-26)                     ALTTIME(13.54.04)
   PMSGDLV(ASPARENT)                       NPMSGDLV(ASPARENT)
   PUBSCOPE(ASPARENT)                      SUBSCOPE(ASPARENT)
   PROXYSUB(FIRSTUSE)                      WILDCARD(PASSTHRU)
   MDURMDL( )                              MNDURMDL( )
)

An MQ Administrator is used in this technote to publish and subscribe to the topic.

In case that you want to use another userid, then review the following technote and provide to that user, the proper authority to publish and subscribe to the topic.
Authorizations needed for non-mqm users to publish and subscribe to Topics in MQ V7

Scenario 1: Publishing from QM1 (where the topic is local) - subscribing from all the Queue Managers

We will be using the following MQ samples provided with the MQ installation:
amqspub topicString QMgr
amqssub topicString QMgr

NOTE:
When using these samples. do NOT use the single quotes to surround the topicString, because they will be considered as part of the topicString.
If there are no special characters in the topicString, then there is no need to surround the topicString with delimiters. It is safe to use double quotes, though:
Correct: amqspub topicString QMgr
Correct: amqspub "topicString" QMgr
Incorrect: amqspub 'topicString' QMgr

Login as an MQ Administrator.
Open 6 windows: 2 for QM1 (one pub, one sub), 3 for QM2 (3 subs with variations) and 1 for QM3 (sub)

First, subscribe to the topic string.
The amqssub waits for 30 seconds for a message. If one is received then it resets the 30 seconds timer. If not, then it terminates.
Thus, a suggestion is that you only type the commands in the 6 screens, but do not press Enter. Then, when all the commands are ready, then proceed quickly to press Enter in each window to activate them.

QM1 Window 1:
amqspub PUBSUBV7 QM1

QM2 Window 1: not using delimiters for the topic string (correct)
amqssub PUBSUBV7 QM2

QM2 Window 2: using double quotes as delimiters for the topic string (correct)
amqssub "PUBSUBV7" QM2

QM2 Window 3: using single quotes as delimiters for the topic string (incorrect)
amqssub 'PUBSUBV7' QM2

QM3 Window 1:
amqssub PUBSUBV7 QM3

Second, publish to the topic string from QM1 (the topic is local):

QM1 Window 1: Enter a brief text, such as: TEST followed by pressing Enter twice. The first Enter is to provide the TEST string, the second is to exit.
amqspub PUBSUBV7 QM1
Sample AMQSPUBA start
target topic is PUBSUBV7
TEST

Sample AMQSPUBA end

Notice that in all the subscribers windows (except one, when the single quotes were used) the output should reveal that the subscribers to the clustered topic were able to receive the message, even when the subscribers were in remote queue managers:

Sample AMQSSUBA start
Calling MQGET : 30 seconds wait time
message <TEST>
Calling MQGET : 30 seconds wait time
no more messages
Sample AMQSSUBA end

In the case when the single quotes were used notice that no messages were received.
Why? Because the string was not PUBSUBV7 (8 characters) but rather 'PUBSUBV7' (10 characters: the 8 for PUBSUBV7, one single quote at the beginning and one single quote at the end) and these strings are different.

$ amqssub 'PUBSUBV7' QM_FR1
Sample AMQSSUBA start
Calling MQGET : 30 seconds wait time
no more messages
Sample AMQSSUBA end

Scenario 2: Publishing from QM2 (where the topic is NOT local) - subscribing from all the Queue Managers

Let's repeat the scenario, with the variation that the publishing will be done from QM2 (which is not the queue manager where the topic is local).
The objective is to show that you can publish from a remote queue manager in the cluster,

Because the warning of not using single quotes was given already, we will use fewer windows and this will simplify the scenario. We will use only 4 windows: 1 for QM1 (sub), 2 for QM2 (one pub, one sub), 1 for QM3 (sub)

QM1 Window 1:
amqssub PUBSUBV7 QM1

QM2 Window 1:
amqssub PUBSUBV7 QM2

QM2 Window 2:
amqspub PUBSUBV7 QM2

QM3 Window 1:
amqssub PUBSUBV7 QM3

Second, publish to the topic string from QM2 (the topic is not local):

QM2 Window 2: Enter a brief text, such as: TEST2
amqspub PUBSUBV7 QM2
Sample AMQSPUBA start
target topic is PUBSUBV7
TEST2

Sample AMQSPUBA end

Notice that in all the subscribers windows the output should reveal that the subscribers to the clustered topic were able to receive the message, even when the publisher was in a remote queue manager (that is, where the topic was NOT a local topic).

Sample AMQSSUBA start
Calling MQGET : 30 seconds wait time
message <TEST2>
Calling MQGET : 30 seconds wait time
no more messages
Sample AMQSSUBA end

CAVEAT about runmqsc:

Please notice that runmqsc treats the double quotes and single quotes in a different manner than the amqspub and amqssub samples.
In runmqsc, ensure to use the single quotes when specifying a topic string.
Lowercase characters not contained within single quotation marks are folded to uppercase.
You cannot use double quotes (it gives a syntax error)
Example: the following topic string exists: sports/baseball
It is defined under a topic object. Notice that it is NOT shown with single quotes nor double quotes.

display topic(T1_CLUS)
     1 : display topic(T1_CLUS)
AMQ8633: Display topic details.
   TOPIC(T1_CLUS)                          TYPE(LOCAL)
   TOPICSTR(sports/baseball)               DESCR( )
   CLUSTER(NEWCLUSTER)                     DURSUB(ASPARENT)

Notice these 3 different responses from runmqsc:

1: Using tpstatus with the topic string surrounded by single quotes: correct

display tpstatus('sports/baseball')
    11 : display tpstatus('sports/baseball')
AMQ8754: Display topic status details.
   TOPICSTR(sports/baseball)               ADMIN(T1_CLUS)
   MDURMDL(SYSTEM.DURABLE.MODEL.QUEUE)
   MNDURMDL(SYSTEM.NDURABLE.MODEL.QUEUE)
   DEFPSIST(NO)                            DEFPRTY(0)
   DEFPRESP(ASYNC)                         DURSUB(YES)
   PUB(ENABLED)                            SUB(ENABLED)
   PMSGDLV(ALLDUR)                         NPMSGDLV(ALLAVAIL)
   RETAINED(NO)                            PUBCOUNT(0)
   SUBCOUNT(0)                             PUBSCOPE(ALL)
   SUBSCOPE(ALL)

2: No quotes: incorrect

display tpstatus(sports/baseball)
    13 : display tpstatus(sports/baseball)

Why? Because they will be folded to uppercase. Thus, above command is equivalent to:
display tpstatus(SPORTS/BASEBALL)
Furthermore, the topic strings are case sensitive. Thus, SPORTS/BASEBALL is indeed a topic string that has not been defined yet.

3: Double quotes: syntax error

display tpstatus("sports/baseball")
    12 : display tpstatus("sports/baseball")
AMQ8405: Syntax error detected at or near end of command segment below:-
display tpstatus("
AMQ8427: Valid syntax for the MQSC command:
  DISPLAY TPSTATUS( generic_topic_string )

Looking at the TOPIC STATUS from QM1 and QM2

We will use the MQ utility "runmqsc" to display the status of the Topic in queue managers QM1 and QM2.

Looking at the TOPIC STATUS from QM1

This command will be run from QM1 (where the topic is local).

Open 5 windows: 3 for QM1 (one for runmqsc, one for pub, one for sub), 2 for QM2 (one pub, one sub).
There will be 2 subscribers (one local, one remote) and 2 publishers (one local, one remote)

QM1 Window 1:
  runmqsc QM1

QM1 Window 2:
amqssub PUBSUBV7 QM1

QM1 Window 3:
amqspub PUBSUBV7 QM1

QM2 Window 1:
amqssub PUBSUBV7 QM2

QM2 Window 2:
amqspub PUBSUBV7 QM2

Notice the command to display the publishers will ONLY show the local publisher (the remote publisher is NOT shown)

display tpstatus('PUBSUBV7') type(pub)
     1 : display tpstatus('PUBSUBV7') type(pub)
AMQ8754: Display topic status details.
   TOPICSTR(PUBSUBV7)                      LPUBDATE( )
   LPUBTIME( )
   ACTCONN(414D5143514D5F414E47454C494C4C4F6606454A20005D01)
   NUMPUBS(0)

Notice that both subscribers (local and remote) are shown.

display tpstatus('PUBSUBV7') type(sub)
     2 : display tpstatus('PUBSUBV7') type(sub)
AMQ8754: Display topic status details.
   TOPICSTR(PUBSUBV7)
   SUBID(414D5120514D5F414E47454C494C4C4F6606454A20005E04)
   SUBUSER(rivera)                         RESMDATE(2009-06-26)
   RESMTIME(14:48:55)                      LMSGDATE( )
   LMSGTIME( )
   ACTCONN(414D5143514D5F414E47454C494C4C4F6606454A20005E01)
   DURABLE(NO)                             SUBTYPE(API)
   NUMMSGS(0)
AMQ8754: Display topic status details.
   TOPICSTR(PUBSUBV7)
   SUBID(414D5120514D5F414E47454C494C4C4F6606454A20001043)
   SUBUSER(MUSR_MQADMIN)                   RESMDATE(2009-06-26)
   RESMTIME(14:48:53)                      LMSGDATE( )
   LMSGTIME( )
   ACTCONN(000000000000000000000000000000000000000000000000)
   DURABLE(YES)                            SUBTYPE(PROXY)
   NUMMSGS(0)

You can use the information provided in ACTCONN to perform a further query to identify the application that is using that connection,
See the published technote: 1375536
Identifying the name of an application that is subscribed to a topic

Looking at the TOPIC STATUS from QM2

This command will be run from QM2 (where the topic is not local).

Open 5 windows: 2 for QM1 (one for pub, one for sub), 3 for QM2 (one for runmqsc, one pub, one sub).
There will be 2 subscribers (one local, one remote) and 2 publishers (one local, one remote)

QM1 Window 1:
amqssub PUBSUBV7 QM1

QM1 Window 2:
amqspub PUBSUBV7 QM1

QM2 Window 1:
amqssub PUBSUBV7 QM2

QM2 Window 2:
amqspub PUBSUBV7 QM2

QM3 Window 4:
  runmqsc QM2

Notice the command to display the publishers will ONLY show the local publisher (the remote publisher is NOT shown)

display tpstatus('PUBSUBV7') type(pub)
     5 : display tpstatus('PUBSUBV7') type(pub)
AMQ8754: Display topic status details.
   TOPICSTR(PUBSUBV7)                      LPUBDATE( )
   LPUBTIME( )
   ACTCONN(414D5143514D5F4652312020202020207106454A20005102
   NUMPUBS(0)

Notice that both subscribers (local and remote) are shown.

display tpstatus('PUBSUBV7') type(sub)
     4 : display tpstatus('PUBSUBV7') type(sub)
AMQ8754: Display topic status details.
   TOPICSTR(PUBSUBV7)
   SUBID(414D5120514D5F4652312020202020207106454A20005A04)
   SUBUSER(rivera)                         RESMDATE(2009-06-26)
   RESMTIME(15:14:31)                      LMSGDATE( )
   LMSGTIME( )
   ACTCONN(414D5143514D5F4652312020202020207106454A20005A01)
   DURABLE(NO)                             SUBTYPE(API)
   NUMMSGS(0)
AMQ8754: Display topic status details.
   TOPICSTR(PUBSUBV7)
   SUBID(414D5120514D5F4652312020202020207106454A20000F24)
   SUBUSER(MUSR_MQADMIN)                   RESMDATE(2009-06-26)
   RESMTIME(15:14:28)                      LMSGDATE( )
   LMSGTIME( )
   ACTCONN(000000000000000000000000000000000000000000000000)
   DURABLE(YES)                            SUBTYPE(PROXY)
   NUMMSGS(0)

Product Alias/Synonym

WebSphere MQ WMQ

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

WebSphere MQ
PubSub

Software version:

7.0, 7.1, 7.5

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows

Reference #:

7016146

Modified date:

2013-05-28

Translate my page

Machine Translation

Content navigation