WU6011-VU6011STUD

7/23/2019 WU6011-VU6011STUD

http://slidepdf.com/reader/full/wu6011-vu6011stud 1/353

IBM WebSphere MQ V7Implementation forExperienced MQ Personnel

(Course code WU601)

Student Notebook

ERC 1.0

5.1

over

Front cover

7/23/2019 WU6011-VU6011STUD


Student Notebook

July 2008 edition

The information contained in this document has not been submitted to any formal IBM test and is distributed on an “as is” basis without

any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer

responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. While

each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will

result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.

© Copyright International Business Machines Corporation 2008. All rights reserved.

This document may not be reproduced in whole or in part without the prior written permission of IBM.

Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions

set forth in GSA ADP Schedule Contract with IBM Corp.

Trademarks

IBM® is a registered trademark of International Business Machines Corporation.

The following are trademarks of International Business Machines Corporation in the United

States, or other countries, or both:

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the

United States, other countries, or both.

Windows is a trademark of Microsoft Corporation in the United States, other countries, or

both.

UNIX® is a registered trademark of The Open Group in the United States and other

countries.

Other company, product, or service names may be trademarks or service marks of others.

i5/OS® IMS™ iSeries®

Notes® RACF® WebSphere®

z/OS®

7/23/2019 WU6011-VU6011STUD


Student Notebook

5.1

OC

Course materials may not be reproduced in whole or in part

without the prior written permission of IBM.

© Copyright IBM Corp. 2008 Contents iii

Contents

Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Course description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Unit 1. Overview and Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2New Version Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3Platform Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5Relationship with Message Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6Publish/Subscribe Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7Publish/Subscribe Admin (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8Publish/Subscribe Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9Publish/Subscribe Application Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10

Publish/Subscribe Application Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11Message Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12Other MQI Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13New Quality of Service Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14WMQ Explorer Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16

Unit 2. Enhanced JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2What is JMS (Java Message Service)? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3The objectives of JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

JMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5JMS Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6Developing a JMS program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7JMS Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8Websphere MQ as a JMS Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10JMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12WebSphere MQ V7 JMS architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13New WMQ V7 features for JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14Multiplexed Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15Asynchronous Consumers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18Asynchronous Puts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19Message Driven Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21Interoperability between MQI and JMS applications . . . . . . . . . . . . . . . . . . . . . . . 2-22JMS Access to MQMD Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26

7/23/2019 WU6011-VU6011STUD


Student Notebook



iv WMQ V7 Impementaion © Copyright IBM Corp. 2008

Unit 3. Publish / Subscribe Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3Point to Point Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4Publish / Subscribe Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5Toward Loose Coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6Loose coupling with Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7

WebSphere MQ V7 and Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8Publish / subscribe applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10Two Types of Distributed Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11Publish/Subscribe in a cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12Hierarchical Distributed Queue Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13Hierarchical and Clustered Queue Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14Concepts – Topic String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15Concepts – Topic Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-16Concepts – Topic Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-17

Concepts – Topic Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18Concepts – Topic Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19Concepts – Topic Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-20Concepts – Topic Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-21Concepts – Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-22Administering Topic Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23Topic Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-24Current Topic Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-25Topic Status – current usage of topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27Administered Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-28Durable vs. Non-Durable Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-29

Retained Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-30Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-31

Unit 4. Publish / Subscribe Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2WebSphere MQ Publish/Subscribe security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3Concepts – Topic Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4Concepts – Topic Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5Concepts – Topic Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6Concepts – Topic Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7Concepts – Topic Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9Externals – Topic security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10Controlling security using MQ Explorer (1 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11Controlling security using MQ Explorer (2 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12Controlling security using MQ Explorer (3 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . .4-13Controlling security using MQ Explorer (4 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14Controlling security using MQ Explorer (5 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . .4-15Controlling security using setmqaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16Check TOPIC security with MQ Explorer (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . .4-17

7/23/2019 WU6011-VU6011STUD


Student Notebook

5.1

OC



© Copyright IBM Corp. 2008 Contents v

Check TOPIC security with MQ Explorer (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . 4-18Check TOPIC security with MQ Explorer (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . 4-19Controlling security using SAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20Controlling security using SAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21Subscription security with SAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22Close Subscription security with SAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23Publish security with SAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24

What happens if...? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25What happens if...? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26What if we rearrange the tree? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27The message is: Think, Plan and Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28The message is: Think, Plan and Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29Pub/Sub Security – MQ vs. Message Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30Basic MQ security on Pub/sub queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32

Unit 5. Publish/Subscribe with the MQ API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3Publish / subscribe applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4Publication explanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5Publishing applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6Set up MQOD and open options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7MQOD C declaration with new fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8Set up MQPMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9Subscription explanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10New API call for subscription registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11New structure for subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12

Non-durable subscription application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14Set up MQSD – subscription description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15Durable subscription application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16Set up MQSD – subscription description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17Return to the durable subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18MQSD -- subscription options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19MQSD – special subscription options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20MQSD – more subscription options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21MQSD – other subscription options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24Set up Close Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27Publications on Request Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28

New API call for subscription requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29New structure for MQSUBRQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30Publish/Subscribe using MQI - Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31New Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32Variable length string - MQCHARV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35

7/23/2019 WU6011-VU6011STUD


Student Notebook



vi WMQ V7 Impementaion © Copyright IBM Corp. 2008

Unit 6. Other MQI Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2WebSphere MQ V7 Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3Message properties in V7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4MQMD properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-5Message properties in MQI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6Why message properties in MQI? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-7

Create message handle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8Inquire message properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10Set message properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-12Message properties compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13Message properties compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-14Message properties compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16What is a message selector? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-18In MQ Version 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-19Selector syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-20API Message selection with MQSUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-24

API Message selection with MQOPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-25Message token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-26Message tokens in WMQ V7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-27Simple browsing application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-28Cloned dispatchers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-29Cloned dispatchers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-30Multiple dispatchers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-31Multiple dispatchers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-32What is Asynchronous Consume ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-33What is an Asynchronous Consumer ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-34An old MQI program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-35

Message Driven ‘C’ single threaded application consuming from two queues . . . .6-36Message Driven ‘C’ multithreaded application consuming from two queues . . . . .6-37Message Driven ‘C’ multithreaded application consuming from two queues . . . . .6-38The called function can be: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-39New APIs to support Async Consume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-40MQCB – Register Message Consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-41MQCTL – Control Consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-42An example of a callback program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-45An example of a callback program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-46An example of a callback program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-47An example of the message consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-48

An example of an external consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-49Asynchronous Consume in a unit of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-50MQGMO_WAIT options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-51Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-52Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-53

Unit 7. New Commands and MQ Explorer Changes. . . . . . . . . . . . . . . . . . . . . . . . . .7-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2Publish/subscribe administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3

7/23/2019 WU6011-VU6011STUD


Student Notebook

5.1

OC



© Copyright IBM Corp. 2008 Contents vii

New queue manager properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4New queue manager properties – MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9DEFINE TOPIC(topicname) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10Topic administration – MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16DISPLAY TPSTATUS(topicstr) TYPE(TOPIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17DISPLAY TPSTATUS(topicstr) TYPE(SUB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20

DISPLAY TPSTATUS(topicstr) TYPE(PUB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22Topic status using wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23Topic status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-25Clear topic string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26Define Sub(string) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28Define Sub(string) [continued] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31Subscription administration – MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-33Display Sbstatus(genericname) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34Subscription status – MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-37Changes to queue alias definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-38New queue alias properties – MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-40Test publish and subscribe – MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-41Browsing message properties – MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-42Usability enhancements for MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-43Welcome Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-44Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-45Grouping of queue managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-46Grouping of queue managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-47Grouping of queue managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-48Grouping of queue managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-49Grouping of queue managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-50

Grouping of queue managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-51MQ Explorer Export / Import Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-52MQ Explorer Export / Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-53Specify userid in MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-54Specify Userid for remote queue manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-55Specify Userid for remote queue manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-56Controlling passwords dialogues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-57What is needed to secure the MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-58Additional object enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-59Changes to server connection channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-60SVRCONN channel properties – MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-62

Read ahead queue property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-63New queue properties – MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-65New connection information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-66Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-67

Unit 8. z/OS Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2New MQ RACF classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3Queue manager attribute – security profile case . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4

7/23/2019 WU6011-VU6011STUD


Student Notebook



viii WMQ V7 Impementaion © Copyright IBM Corp. 2008

Changes to REFRESH SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5Understand mixed case profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6Upper case only profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-7Mixed case profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8Refreshing mixed case profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9MQ Explorer without CAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10Authentication using MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11

Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-12

Unit 9. Client Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4MQ V6 multithreaded clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5MQ V7 multithreaded, multiplexing clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6Shared Conversations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7Shared Conversations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8

Shared conversation coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9Shared conversation administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10Asynchronous Put (“fire and forget”) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-11MQPUT in binding mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12MQPUT in V6 client mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-13MQPUT in client mode with Async Put . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-14New Put Message Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15When “Fire and Forget” applies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-17Sync Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-19The MQSTAT call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-20The MQSTS structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-23

Queue Definition Default Put Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-24Read ahead (client streaming) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-25MQGET in binding mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-26MQGET in V6 client mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-27MQGET in client mode with Read Ahead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-28New MQOPEN Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-29New MQSUB Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-31New MQCLOSE Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-32Configuring the client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-34Complete change of Java Exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-37Using a Client exit written in C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-38

Using a Client exit written in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-39Using a Client exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-40Why would we like to control SVRCONN ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-41Control number of SVRCONN connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-42Number of clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-43Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-44

Unit 10. Co-existence and migration of MQ / Message Broker Publish/Subscribe10-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2

7/23/2019 WU6011-VU6011STUD


Student Notebook

5.1

OC



© Copyright IBM Corp. 2008 Contents ix

Overview of MQ V7 publish/subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3PSMODE: New queue manager attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4Coexistence: compatibility window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5Coexistence support (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6Coexistence support (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7Coexistence support (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8MQ V6 publish/subscribe migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9

Control commands used in migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10Migration procedures (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11Migration procedures (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-12Enabling and disabling PSMODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13Migration recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-14Deprecated function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15MQ for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16In summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-17Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-18

7/23/2019 WU6011-VU6011STUD


Student Notebook



x WMQ V7 Impementaion © Copyright IBM Corp. 2008

7/23/2019 WU6011-VU6011STUD


Student Notebook



© Copyright IBM Corp. 2008 Trademarks xi

5.1

MK Trademarks

The reader should recognize that the following terms, which appear in the content of this

training document, are official trademarks of IBM or other companies:

IBM® is a registered trademark of International Business Machines Corporation.

The following are trademarks of International Business Machines Corporation in the United

States, or other countries, or both:

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the

United States, other countries, or both.

Windows is a trademark of Microsoft Corporation in the United States, other countries, or

both.UNIX® is a registered trademark of The Open Group in the United States and other

countries.

Other company, product, or service names may be trademarks or service marks of others.

i5/OS® IMS™ iSeries®

Notes® RACF® WebSphere®

z/OS®

7/23/2019 WU6011-VU6011STUD


Student Notebook



xii WMQ V7 Impementaion © Copyright IBM Corp. 2008

7/23/2019 WU6011-VU6011STUD


Student Notebook



© Copyright IBM Corp. 2008 Course description xiii

5.1

ef Course description

IBM WebSphere MQ V7 Implementation for Experienced MQ Personnel

Duration: 2 days

Purpose

In this course, you will learn about JMS and MQI enhancements, new

Pub/sub capabilities, and new commands and Explorer

enhancements. You will also be introduced to the new WMQ V7

enhancements that apply specifically to z/OS.

This course includes several lab exercises to allow you to gain

hands-on experience with the new and extended capabilities of

WebSphere MQ V7.

Audience

This course is designed for experienced WebSphere MQ

administrators and developers who are new to WebSphere MQ V7.

Prerequisites

Before taking this course, students should have a working knowledge

of WebSphere MQ.

Students should also be reasonably familiar with, and be able to

invoke simple function within, the operating system environment for

the practical exercises.

Objectives

After completing this course, you should be able to:

• "Utilize WMQ V7 improvements for Pub/Sub

• "Utilize WMQ V7 improvements to JMS

• "Explain and utilize the ease-of-use enhancements for

administrators in WMQ V7

• "Explain and utilize the ease-of-use enhancements for MQI

programmers in WMQ V7

7/23/2019 WU6011-VU6011STUD


Student Notebook



xiv WMQ V7 Impementaion © Copyright IBM Corp. 2008

7/23/2019 WU6011-VU6011STUD


Student Notebook



© Copyright IBM Corp. 2008 Unit 1. Overview and Architecture 1-1

5.1

empty Unit 1. Overview and Architecture

What this unit is about

The purpose of this unit is to introduce the overall changes made to

WebSphere MQ Version 7. The information in this unit will beexpanded upon in the following units of the course.

What you should be able to do

After completing this unit, you should be able to:

• Understand the objectives behind the design of WebSphere MQ

Version 7.

• Know the platforms to be covered in Version 7.

• Describe the overall changes to Version 7.

• Improvements to publish/subscribe

• Improvements to JMS/XMS layer

• Ease-of-use for administrators

• Ease-of-use for MQI programmers

• Performance

• Tighter integration with Message Broker

How you will check your progress

• Class discussion

References

WebSphere MQ V7 manuals

7/23/2019 WU6011-VU6011STUD


Student Notebook



1-2 WMQ V7 Impementaion © Copyright IBM Corp. 2008

Figure 1-1. Unit objectives WU6011.0

Notes:

© Copyright IBM Corporation 2008


• Understand the objectives behind the design of WebSphereMQ Version 7.


• Describe the overall changes to Version 7. – Improvements to publish/subscribe

– Improvements to JMS/XMS layer

– Ease-of-use for administrators

– Ease-of-use for MQI programmers

– Performance

– Tighter integration with Message Broker








– Performance


Unit objectives

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 1-2. New Version Objectives WU6011.0

Notes:


New Version Objectives

• Improved support for "standards-based" messaging – Underpinning SOA and ESB architectures

– Ease-of-use – Performance

• Extension of publish/subscribe capabilities – Leading to simplification with Message Broker

• Easier programming in any environment – Some features suggested by JMS requirements are useful in MQI

• Common across Distributed and z/OS codebases

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 1-3. Platform Coverage WU6011.0

Notes:


Platform Coverage

• Essentially the same platforms as V6 – Minor updates to base OS levels

• Linux based on RH4 or Suse 9; AIX V5.3; z/OS 1.8 (GA 3Q06)

• Drop Linux/zSeries 31-bit – 64-bit edition will continue

• Drop Windows 2000 – Windows XP is base level – Will include Vista

• Windows 2003 x86-64 support – Adds 64-bit application support – Supporting existing 32-bit applications – Some exits will require recompiling to support both 32 and 64-bit modes

• Java 1.4 and later

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 1-4. Publish/Subscribe WU6011.0

Notes:


Publish/Subscribe

• Point-to-point asynchronous messaging decouples applications – But still implies a one-one relationship between sender and receiver

• Publish/subscribe is a further stage of decoupling – Sender has no direct knowledge of how many (if any) apps will see a

message

– Link between applications is a Topic, not a Queue

• A natural part of the JMS API – Combined both Publish/Subscribe and Point-to-Point styles

– Want to make it a natural part of the native MQI

• WMQ V5.3 and V6 (Distributed) included a Publish/Subscribe broker

(SupportPac MA0C)

• Available for the first time on z/OS without installing Message Broker

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 1-5. Relationship with Message Broker WU6011.0

Notes:


Relationship with Message Broker

• Next version of Message Broker will prereq this version of WMQ for

pub/sub

– But WMB V6 will continue to work with new WMQ releases – Migration can be done one piece at a time

• The publish/subscribe engine is removed from the broker – The Nodes will call the WMQ engine transparently

– Message Flows do not need to be changed

• Administration tooling will be integrated with WMQ tooling – One place to configure WMQ and WMB resources

– V6 SupportPacs show direction

• Looking for any other optimisations ... – Vision is all TRANSPORT is in WMQ

• For example, multicast

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 1-6. Publish/Subscribe Admin WU6011.0

Notes:


Publish/Subscribe Admin

• Based on Topics

• Topic Objects – New object type, like queue or channel definitions – A 48-character name which has a longer attribute for full topic string – Defines major points in a topic tree

• In-use topics – The topic strings that applications are publishing or subscribing on – Inherit attributes (eg security) from the "closest" defined topic object – Not defined administratively, but can be viewed

/

NEWSSPORTS

CRICKET RUGBY

DEFINEDTOPIC TREE

IN-USETOPICS

SUBSCRIBE("/SPORTS/CRICKET/WEST INDIES")

SUBSCRIBE("/NEWS/POLITICS/WESTMINSTER")

SUBSCRIBE("/TV/DRAMA/WEST WING")

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 1-7. Publish/Subscribe Admin (2) WU6011.0

Notes:


Publish/Subscribe Admin (2)

• Support for durable and non-durable subscriptions – With durable, a client can go away and come back later without missing

messages – Durable can cause queues to fill ...

– No "cleanup" task needed for non-durable

• Subscriptions – Able to see who is subscribing to topics: like DISPLAY QSTATUS

– Able to create subscriptions on behalf of a third party

• Security

– Use of a topic is restricted by permissions on the associated topic object – On z/OS drives need for mixed-case support in RACF

– Follows existing WMQ model for security configuration (RACF or OAM)

• Conversion of point-to-point applications without code changes – Administrative changes to objects

– A queue alias can point to a topic, not just a local queue

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 1-8. Publish/Subscribe Topologies WU6011.0

Notes:

The availability features in hub/spoke give us the same as clones – in fact better - without

explicitly having to create such an entity.


Publish/Subscribe Topologies

• WMQ V6 publish/subscribe networks based on hierarchies – All brokers linked in parent/child tree

• WMB publish/subscribe networks based on hierarchies of collectives – All systems in a collective are connected to each other (mesh)

– Also has "clones“

• New product will have hierarchies and clusters – With interoperability to other pub/sub systems through hierarchies

• Design gives

– Scalability – Availability

– Ease of administration

• Collectives based on WMQ clustering – Cluster can be defined independently of any existing cluster used for

queuing

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 1-9. Publish/Subscribe Application Programming WU6011.0

Notes:


Publish/Subscribe Application Programming

• Cannot significantly change the JMS API – But we want to make some of its facilities more easily available in the MQI

– To improve MQI programming and improve (make thinner) the JMS layer – JMS implementation will exploit new MQI functions

• New verb for subscribing – So you do not need to build RFH or RFH2 headers in the application – MQSUB registers a subscription

• Includes information about where messages will be read from• Do not need to specify a queue – can be automatically assigned

• New options on existing verbs – MQOPEN to get access to a topic

– MQCLOSE will deregister a subscription – MQPUT, MQGET to publish and to receive subscriptions

• Conversion of point-to-point applications without code changes – Administrative changes to objects

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 1-10. Publish/Subscribe Application Migration WU6011.0

Notes:


Publish/Subscribe Application Migration

• New verbs remove need for some of the older interfaces – Which will be deprecated – though not removed immediately

– PCF and RFH1 facilities for WMQ publish/subscribe applications: Identity,Streams

• New MQI operations not be available for old VB and ActiveX programs – Use .Net classes instead

• A single application cannot mix new verbs with old options – Can't use RFH1(Register Publisher) and MQPUT(topic) in same program

• Option available to translate old-style pub/sub commands – Both RFH and RFH2 interfaces for WMQ and WMB pub/sub applications – Not needed when all publish/subscribe applications have been converted

• Migration step to convert existing WMQ and WMB subscriptions

• Most common "application" is IBM-supplied JMS layer – Client design to take advantage of new facilities when they exist – So installing new JMS jar is all that's needed

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 1-11. Message Properties WU6011.0

Notes:


Message Properties

• Arbitrary values associated with the message but not part of the body – Like a user-extendable MQMD

– Already part of JMS

• New verbs MQSETMP and MQINQMP – Properties can be integers, strings, Boolean, etc.

• Easier to use than RFH2 folders – Receiving apps do not see them unless they want

– No need to parse and skip over message headers

• Configuration options for compatibility

– Queue and channel attributes define behavior – Defaults will create RFH2 folders

• Permits explicit statement of relationships between messages – e.g. Message X is a REPLY to Message Y

– Which can then be exploited by products looking for patterns

MQMD

BODY

PROPS

XX=YY

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 1-12. Other MQI Enhancements WU6011.0

Notes:


Other MQI Enhancements

• Asynchronous message reception – New verb MQCB defines a callback function

– Automatically Invoked when a message arrives – No need for MQGET(WAIT) or MQGET(SIGNAL)

• Selectors – Use a SQL92 clause to select messages by properties including MQMD

fields

– Can be specified on MQOPEN, MQSUB for filtering messages

– Filtering is normally done inside queue manager for efficiency

– Not filtering on message body contents

• Message Broker still required for content filtering

• Cooperative browsing and message tokens – Efficient interface for application reading from the same queue

– Example: “master” program browses a queue telling “slaves” which

message to work with, based on elements with the message

– Messages locked but available to any cooperating process

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 1-13. New Quality of Service Options WU6011.0

Notes:

Early indication:

50 seconds for one test using local bindings; 480 -> 110 seconds for remote clients


New Quality of Service Options

• Traditional WMQ non-persistent messages more reliable than someneed

• Receiving Messages/Subscriptions: – Messages sent to a client in advance of MQGET, queued internally – Administrative choice – no application changes needed – Higher performance in client

• Sending/Publishing Messages: – Application can indicate it doesn't want to wait for the return code

• Maybe pick up return code later – MQSTAT verb – Maintains transactional semantics – Higher performance in client

• Implementation also gives us more heartbeat opportunities – Faster failure notification for clients

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 1-14. WMQ Explorer Enhancements WU6011.0

Notes:


WMQ Explorer Enhancements

• Sets – Queue Managers can be partitioned into groups within the Navigator

– For example "Test", "Production“

• Security Configuration – Easy to define channel exits, userid/password configurations

– Configured for each queue manager or all queue managers in a set

– Password manager included

– Still recommend security exit for authentication at the server

• Tighter JMS integration

– Creating an queue/topic can define a JMS destination at the same time

• Message browser configuration – Number and size of messages to be browsed

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 1-15. Unit summary WU6011.0

Notes:


Having completed this unit, you should be able to:







– Performance









– Performance


Unit summary

7/23/2019 WU6011-VU6011STUD


Student Notebook



© Copyright IBM Corp. 2008 Unit 2. Enhanced JMS 2-1

5.1

empty Unit 2. Enhanced JMS


This unit describes the changes that have been made to the JMS

interface as used in WebSphere MQ Version 7.



• Understand JMS concepts

• Understand the role MQ plays as a JMS provider

• Understand the enhancements made for the WebSphere MQ V7

JMS implementation.

• Understand the benefits for developers, administrators and

operations staff when using WebSphere MQ V7 as the JMS

provider.



ReferencesWebSphere MQ V7 manuals

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Understand JMS concepts• Understand the role MQ plays as a JMS provider

• Understand the enhancements made for the WebSphere MQ

V7 JMS implementation.



provider.







provider.

Unit objectives

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 2-2. What is JMS (Java Message Service)? WU6011.0

Notes:

Java Community Process

JMS was initially defined by Sun Microsystems in collaboration with Java industry partners,

along with other similar specifications such as J2EE, JTA etc. These specifications are

typically managed under the Java Community Process which is an industry partnership for

defining and agreeing enhancements to such specifications (and new specifications for

Java technologies).

Programs written with JMS can run on any messaging system that implements the JMS

standard.


What is JMS (Java Message Service)?

• JMS is a fixed API defined by the JMS

1.1 Specification, managed by the Java

Community Process.

• The JMS API is provided as a set of

interfaces. Product providers of JMS

implement these interfaces.

• JMS allows Java programmers to

access messaging systems in a

common manner.

• The Java Message Service

specification 1.1 states: JMS is a set ofinterfaces and associated semantics

that define how a JMS client accesses

the facilities of an enterprise messaging

product.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 2-3. The objectives of JMS WU6011.0

Notes:


The objectives of JMS

• The objectives of JMS as stated in the specification are to:

– Define a common set of messaging concepts and facilities.

– Minimize the concepts a programmer must learn to use enterprise messaging.

– Maximize the portability of messaging applications.

– Minimize the work needed to implement a provider.

– Provide client interfaces for both point-to-point and publish/subscribe domains.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 2-4. JMS Architecture WU6011.0

Notes:

The details of each component in the diagram are presented in the next slide.

The JMS Client represents the application. The JNDI Namespace is for the Administered

objects. The Messaging Provider is for example Websphere MQ.


JMS Architecture

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 2-5. JMS Building Blocks WU6011.0

Notes:

Explaining the diagram in Websphere MQ terms:

• Connection provides a place to hold the parameters that control how to connect to

WMQ, e.g. QMgr name, hostname for remote connections, etc

• Destination defines a queue or topic

• Session defines an HCONN and therefore a transactional scope

• Producer/Consumer contains an HOBJ for putting/getting


JMS Building Blocks

• Connection Factory: An administeredobject that creates a connection to theprovider's underlying messaging

system.

• Connection: An active connection to aprovider.

• Session: A single-threaded context forsending and receiving messages.

• Message Producer : Used for sendingmessages.

• Message Consumer : Used forreceiving messages.

• Destination: An administered objectthat encapsulates the identity of amessage destination, such as wheremessages are sent to or received from.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 2-6. Developing a JMS program WU6011.0

Notes:


Developing a JMS program

• A typical JMS program goes through the following steps to begin producing

and consuming messages:

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 2-7. JMS Messages WU6011.0

Notes:

Header All messages support the same set of header fields. Header fields contain values

that are used by both clients and providers to identify and route messages.

Properties Each message contains a built-in facility to support application-defined property

values. Properties provide an efficient mechanism to filter application-defined messages.

Body JMS defines several types of message body that cover the majority of messaging

styles currently in use. JMS defines five types of message body:

Text A message containing a java.lang.String.

Stream A stream of Java primitive values. It is filled and read sequentially.

Map A set of name-value pairs, where names are strings and values are Java primitive

types. The entries can be accessed sequentially or randomly by name. The order of the

entries is undefined.

Bytes A stream of uninterpreted bytes. This message type is for literally encoding a

body to match an existing message format.


JMS Messages

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty Object a message that contains a serializable Java object

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 2-8. Websphere MQ as a JMS Provider WU6011.0

Notes:

WMQ JMS

The WMQ JMS implementation, a.k.a. MQ Classes for JMS, is that defined within

com.ibm.mq.jms.*, not to be confused with the WMQ Classes for Java in com.ibm.mq.*,

which is a Java OO form of the MQI.

Performance

By ‘performance improvements’, we mean any enhancement that improves the runtime

behaviour of the WMQ JMS implementation in terms of the efficient use of resources.

Typically these would be seen as increased message throughput, enhanced scalability tomore client connections, reduced network socket or bandwidth usage, reduced CPU or

memory usage etc.

Usability

By ‘usability improvements’, we mean any enhancement to the ease of use of WMQ by

JMS developers, administrators etc. These may be in installation, configuration,

documentation, administration and monitoring tools, development tools, problem

determination assistance, samples, demonstration applications etc.


Websphere MQ as a JMS Provider

• IBM provides an implementation of JMS over WMQ called Websphere

MQ classes for Java Message Service (also referred to as Websphere

MQ JMS) – IBM also has other JMS implementations for other messaging environments

– Many other messaging vendors also provide JMS implementations

• IBM is enhancing its WMQ JMS implementation to make it more

effective – Largely through all the new WMQ features in v7

– JMS API exposes these enhancements, typically as performance or usability

improvements

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty In JMS implementations, the wire format of messages is typically proprietary. JMS

implementations should use a common API but should not be expected to interoperate with

each other, i.e. the JMS spec is for portability and not interoperability.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 2-9. JMS Architecture WU6011.0

Notes:


JMS Architecture

MQ

MQ API

MQ Classes

for JMS

MQ Queues / Topics

MQ/QMgr details

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 2-10. WebSphere MQ V7 JMS architecture WU6011.0

Notes:


WebSphere MQ V7 JMS architecture

• Prior to MQ V7, a gap existed between the functionality specified in JMS and that

provided in the MQI, e.g. selectors in JMS, not in MQ API requiring WMQ Classes

for JMS to perform the work.

• Native WMQ API now supplies functionality such as Asynchronous Consumers and

Selectors. Now WMQ JMS Classes are simpler and more efficient.

WMQ

JVM

JMS AppsWMQ

Classes for

JMS

JNDINamespace

APIConversion

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 2-11. New WMQ V7 features for JMS WU6011.0

Notes:

A set of features to be implemented in WebSphere MQ v7.0 will enhance the performance

and usability of the product as a JMS provider. This set of features is being implemented

under a series of DCRs to make modifications to the main product implementation and API,

in addition to a series of DCRs to provide a new JMS (and XMS for C/C++) implementation

making use of these underlying product enhancements.

This will provide equivalent functionality to the previous implementation used in earlier

releases of the product, so as to both meet the JMS Specification and ensure that

applications migrated from earlier releases to this new implementation continue to behavein the same way. The purpose of the new implementation is to enhance usability of

WebSphere MQ when using the JMS API and/or enhance runtime performance, not to

provide additional functionality.


New WMQ V7 features for JMS

• There are a number of JMS performance and interoperability

enhancements provided in Websphere MQ V7, mainly as a result of

providing JMS functionality previously held in JMS classes in to thenative MQ API.

– Multiplexed Connections

– Asynchronous Consumers

– Selectors

– Non-blocking Producers

– Message Driven Beans

– Publish/subscribe, as well as point-to-point messaging

– Interoperability between JMS and other WMQ applications

C

S S S

hC

hC hC hC

JMS Client WMQ Queue Manager

Socket

Consumer

Consumer xx

Producer

J2EE App Server

MDBMDB

MDB

Consumer Consumer

Consumer

Producer

WMQ AppJMS App

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 2-12. Multiplexed Connections WU6011.0

Notes:

• Exploits shared socket (multiplexing) functionality being added to underlying v7 API, i.e.

multiple client connections share the same physical socket connection with multiplexed

conversations identified using unique conversation IDs.

Benefit: Increased vertical scalability allowing more JMS sessions within a client

process before running out of socket resources.

• Enhancements invisible to Application Developer.

- Share con parameter: The sharingConversations field is used on connections from

JAVA applications, when these applications do not specify a client channel definition

table and are not issuing an MQCONNX call.

sharingConversations determines the maximum number of conversations that can

be shared on a socket associated with this connection.

A value of 0 means that the channel operates as it did before WebSphere MQ

Version 7.0, with regard to conversation sharing, read ahead, and heartbeat.


Multiplexed Connections

• For JMS clients

• Conversation sharing (multiplexing) allows a single TCP/IP socket tocarry multiple JMS sessions with a connection.

• Prior to WMQ V7, each Session had an HConn, the first Session

sharing its HConn with the parent Connection. Each HConn used a

separate network socket for client connections. Extra HConns were

also used for temporary destination management, cleanup processes

etc.

• With WMQ V7, JMS Sessions can share a single socket and thereforeone instance of the SVRCONN channel.

• Benefit: Reduced socket usage allowing vertical scalability.

C

S S S

hC

hC hC hC

JMS Client WMQ Queue Manager

Socket

7/23/2019 WU6011-VU6011STUD


Student Notebook




The field is passed in the hash table of properties as a

SHARING_CONVERSATIONS_PROPERTY, when instantiating a WebSphere MQ

queue manager.

If you do not specify sharingConversations , a default value of 10 is used.

(performance > with share con = 1 but lots of open sockets)

E.g. 1 Connection + 11 Sessions => 2 sockets, 1 for the connection and 1 for the sessions

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 2-13. Asynchronous Consumers WU6011.0

Notes:

Asynchronous consuming achieved by message listeners being driven by the MQI rather

than having to poll a destination.


Asynchronous Consumers

• A JMS Consumer can either make synchronous receive() calls to get

messages, or can register a callback, using MessageListener, to be

called asynchronously when a message arrives.

• Prior to WMQ V7, WMQ only natively supported the synchronous mode

of operation. The JMS implementation therefore had to poll for

messages.

• By adding asynchronous consumer support into the MQI, the JMS

implementation can be hugely simplified and optimised.

• Benefits: – Simplified JMS implementation, therefore easier maintenance.

– Improved message throughput.

– Reduced time lag from message arrival to delivery.

– Reduced client and server CPU usage and network traffic.

Consumer

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 2-14. Selectors WU6011.0

Notes:

Selection done within the queue manager – passing the Selector string to the queue

manager on creation of the Message Consumer rather than having to browse and match

messages in the client.

On z/OS, selectors are for pub/sub only and not for PTP.


Selectors

• Prior to WMQ V7, WMQ only natively supported selection by Message

ID and Correlation ID.

• The JMS specification required selection on all header and property

fields. The JMS implementation therefore had to browse for

messages, compare them to the selection criteria, then get the ones

that match.

• By adding full selector support to the queue managers in WMQ V7,

the JMS implementation can be hugely simplified and optimised.

• Benefits: – Simplified JMS implementation.

– Improved message throughput when using general selectors.

– Reduced time lag from message arrival to delivery.

– Reduced client CPU and memory usage, and reduced network traffic.

Consumer xx

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 2-15. Asynchronous Puts WU6011.0

Notes:

Messages can be sent to destinations without requiring the sending application to wait for

the full line turnaround.

Asynchronous Put is also known as “fire and forget” and as non-blocking producers. It is

not designed for put/get scenarios.

This option instructs the session to lazily acknowledge the delivery of messages. This is

likely to result in the delivery of some duplicate messages if JMS fails, so it should be used

only by consumers that are tolerant of duplicate messages. Its benefit is the reduction of

session overhead achieved by minimizing the work the session does to prevent duplicates.


Asynchronous Puts

• Prior to WMQ V7, an application producing messages had to wait for a

response from the queue manager each time it put a message onto the

queue, even if the application did nothing with the response.

• By adding Asynchronous Puts (a.k.a. non-blocking producers),

applications can choose not to wait for the queue manager to respond

and continue with other work, such as preparing the next message to

send.

• Delayed periodic checks can be added to the application to determine

whether any problems have occurred in sending the messages. For

transactional sessions, this check happens at the point of a COMMIT.

• Benefit: Improved message throughput for producer applications.

Producer

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 2-16. Message Driven Beans WU6011.0

Notes:

Message Driven Beans take advantage of WMQ V7 features Asynchronous Consumers,

Selectors and Read Ahead as described in previous slides.


Message Driven Beans

• A J2EE Application Server can use JMS to cause a Message Driven

Bean (MDB) to be invoked as a result of a message arriving at a

specified destination.

• A JMS provider works in concert with the application server to deliver

the messages via Connection Consumers to JMS Sessions taken from

a pool, and hence to the MDBs.

• Prior to WMQ V7, WMQ JMS had to poll for messages before being

able to deliver them to the MDBs.

• By adding asynchronous consumer and selector support, as well asclient read-ahead, optimisations can be made.

• Benefits: – Improved message throughput for MDBs.

– Reduced CPU and memory usage within the application server.

J2EE App Server

MDBMDB

MDB

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:

The details of pub/sub will be explained in the pub/sub presentations. This is only intended

to be a high level view with the intention of showing how usability and performance are

increased for JMS clients.


Publish/Subscribe

• Prior to WMQ V7, WMQ had historically been a point-to-point queuemanager, with added publish/subscribe broker support via a scheme

involving control queues, publication queues and subscription queues.

• By adding native publish/subscribe support into WMQ V7, topics aretreated as first-class objects like queues, thus simplifying administrationand subscription.

• Messages are published to topics rather than being put to publicationqueues for a broker to then send to subscribers.

• JMS publish/subscribe is possible on z/OS with WMQ V7. z/OS has not

previously had a WMQ publish/subscribe engine.

• Benefits: – Direct administration of topics and their security characteristics. – Removal of complexity in broker queue management. – Increased throughput for persistent messages due to removal of

publication queues.

Consumer Consumer

Consumer

Producer

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 2-18. Interoperability between MQI and JMS applications WU6011.0

Notes:

A JMS message can have any number of named properties, a subset of which are

recognized by the JMS provider as indicating a requirement for particular message

handling. The new property to be recognized is the JMS_IBM_RETAIN property. If set to

a recognized value when sent to a topic destination, this property indicates that the

message is to be treated as a retained publication for that topic, replacing any previous

retained publication.

The JMS Message classes provide facilities to populate and query the contents of

messages, either created locally or received from other applications via point to point orpublish/subscribe messaging. The API is fixed by the JMS Specification, and the internal

format is fixed by the underlying WebSphere MQ product specification, so the only points of

flexibility are the mapping between JMS definitions and WebSphere MQ definitions, the

efficiency of the processing involved in populating, parsing, sending and receiving

messages, and the set of named properties within messages supported and recognized by

the other JMS components.


Interoperability between MQI and JMS applications

• JMS messages have a more complex structure than simple WMQmessages, using message headers to store JMS header and propertyinformation.

• Prior to WMQ V7, performing publish/subscribe messaging over WMQwithout using JMS was difficult, with applications forced to managebroker control, subscription messages, and RFH parsing, which JMSdoes for them.

• By adding native message properties support into WMQ, it is mucheasier for MQI-based applications to access the JMS header fields andproperties without using the JMS API.

• By adding native publish/subscribe support into WMQ, MQI-basedapplications can more easily participate in the same publish/subscribenetworks as JMS applications.

• Benefit: – Simplified extension of existing MQI-based applications to participate in

messaging with JMS applications, enabling easier integration ofheterogeneous messaging applications.

WMQ AppJMS App

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty For existing header fields, named properties and message bodies, there is no change in

the mapping between JMS and WebSphere MQ for this release.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 2-19. JMS Access to MQMD Fields WU6011.0

Notes:

Some customers have been asking for better access to native MQ messages (MQMD and

payload) through the JMS API. Typically, this is because they like all the benefits of the

JMS API, but really need to work with MQ messages rather than JMS messages, usually

because they require interoperation with non-JMS applications. Classic examples are

being able to set the ApplicationID in the MQMD because a receiving application expects it

to contain certain values rather than the value JMS puts in by default, or being able to

directly work with the contents of an RFH2 rather than having JMS convert it into properties

and hide some elements of the RFH2 from the application, or being able to explicitly set the

MessageID when sending a message. Note that using some of this requires additional

authorities (e.g. opening a queue with context authority so that the UserID or ApplicationID

of a message can be set by the sending application), hence the need for configuration

properties in the Destination. Note also that using these new features will make a JMS

application very MQ-specific and in some cases (e.g. setting the MessageID on send) will

make our JMS implementation work in non-spec-compliant ways. We accept these as

concerns but believe that the benefits far outweigh the concerns; i.e. we are doing what is

useful to MQ/JMS customers rather than taking a blinkered spec-compliance approach.


JMS Access to MQMD Fields

• Customers have been asking for better access to native MQ messages

(MQMD and payload) through the JMS API because they require

interoperation with non-JMS applications.

• Considered advanced usage of MQ/JMS - useful to MQ/JMS customers

who are willing to extend the JMS spec.

• Customers will be able to read/write MQMD fields when using the JMS

API

• Users can now PUT to a queue or a topic with the message body

containing the application payload as-is without an auto-generatedWMQ header (MQRFH2) added to the body.

• 27 new properties for a JMS Message, e.g. JMS_IBM_MQMD_Priority,

JMS_IBM_MQMD_Persistence, JMS_IBM_MQMD_CorrelId.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 2-20. Benefits WU6011.0

Notes:


Benefits

Aims:

• WMQ provides more support to a JMS application developer.• WMQ is easier to configure and manage as a JMS provider.• WMQ has improved runtime performance for JMS applications.• WMQ is easier to demonstrate and deploy as a JMS provider.

• Existing applications will continue to work with new JMS client when connected tocurrent queue manager.

• Many improvements to existing applications by using new JMS client and queuemanager together.

• Further improvements for new, reconfigured or ‘tweaked’ applications to explicitlyuse new features.

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:








provider.







provider.

Unit summary

7/23/2019 WU6011-VU6011STUD


Student Notebook



© Copyright IBM Corp. 2008 Unit 3. Publish / Subscribe Concepts 3-1

5.1

empty Unit 3. Publish / Subscribe Concepts


This unit describes the basic concepts of publishing and subscribing,

and how those concepts have been implemented in WebSphere MQVersion 7. We will look at the new topic objects, and discuss how the

connection between a topic object and a topic string.



• Understand the concepts of publishing and subscribing.

• Describe the use of the topic string in connecting subscribers with

publications.

• Understand a topic hierarchy.

• Describe the WebSphere MQ V7 Publish/Subscribe commands.

• Understand durable vs. non-durable subscriptions.


• Class discussion and lab exercise

References


7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Understand the concepts of publishing and subscribing.• Describe the use of the topic string in connecting subscribers

with publications.


• Describe the WebSphere MQ V7 Publish/Subscribe

commands.




with publications.



commands.


Unit objectives

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:

Although Wikipedia is hardly a definitive reference work, this is a useful definition. Pub /

Sub is certainly a paradigm. A decision to use pub/sub can effect how we design our

applications. Pub / Sub says little or nothing about the payload of messages being

distributed.


Publish/Subscribe

• Publish/Subscribe (or pub/sub) is an asynchronousmessaging paradigm where senders (publishers) ofmessages are not programmed to send their messages tospecific receivers (subscribers). Rather, publishedmessages are characterized into classes, withoutknowledge of what (if any) subscribers there may be.

• Subscribers express interest in one or more classes, andonly receive messages that are of interest, withoutknowledge of what (if any) publishers there are. Thisdecoupling of publishers and subscribers can allow forgreater scalability and a more dynamic network topology.

• Pub/sub is a sibling of the Message Queue paradigm, and

is typically one part of a larger Message-OrientedMiddleware solution. Most messaging systems support intheir API (e.g. JMS) both the pub/sub and Message Queuemodels.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 3-3. Point to Point Examples WU6011.0

Notes:

The original method for MQ messaging is point to point messaging. In the same way, it is

not the message content that makes an application point to point or pub/sub. It is the

infrastructure that handles the message.


Point to Point Examples

• Post Card

–Goes to just the person I send it to.• eMail –Might go to lots of people but I get to choose exactly

who gets it.

• Message Queuing – If I put a message it will go to one consumer.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 3-4. Publish / Subscribe Examples WU6011.0

Notes:

Publishers use the magazine title and advertising to indicate the contents. We readers

select which magazine to pick up based on that information.


Publish / Subscribe Examples

• Magazine Publishing – In the UK - 3,366 titles

published

• Airline Departure Boards – Boards might display

(subscribe to)

• All departures, or

• Departures at this terminal,

or

• Departures by this airline

• BBC RSS News Feeds

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 3-5. Toward Loose Coupling WU6011.0

Notes:


Toward Loose Coupling

• Monolithic – Work is all on one computer !

• Client-Server – Work is distributed, but detailed knowledge of topology and

connectivity needed all components need to be available together.

• Message Queuing – Cooperating components can work at different pace. Work will queue

at busy times or if a component is down. Connected by Queue

Names.

• Publish/Subscribe – Cooperating components exchange data through an infrastructure that

identifies the “subject” of the data.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 3-6. Loose coupling with Publish/Subscribe WU6011.0

Notes:


Loose coupling with Publish/Subscribe

Publisher

Subscriber

T o pi c

Provider

Subscriber

Subscriber

Subscriber

Publisher Publisher Publisher

Subscriber

T o pi c

T o pi c

Publisher Publisher

Subscriber Subscriber

T o pi c

1:1 1:many many:1 many:many

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 3-7. WebSphere MQ V7 and Publish/Subscribe WU6011.0

Notes:

Notes :


WebSphere MQ V7 and Publish/Subscribe

• Central concept is the TOPIC STRING.

• Messages are “published” to a TOPIC STRING. – Each publishing action is to a single TOPIC STRING.

• Subscribers are delivered messages that were published to the TOPIC

STRINGS that they subscribe to. – Subscribers may be subscribing to many topics, and may use wild cards in topic

names.

• TOPIC STRINGS are organized into a logical hierarchy.

• TOPIC STRINGS can be created and secured administratively, or bybeing used for Publish or Subscribe.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 3-8. Publish / subscribe applications WU6011.0

Notes:


Publish / subscribe applications

Subscribing App

L o c a l Q M g r L

o c al QM gr

• Applications connect to local queue manager

• In general they will be different queue managers connected by a

network.

• Can use JMS/XMS or any MQI language

Publishing App

QM QMPublish/SubscribeNetwork

Publish/SubscribeNetwork

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 3-9. Subscriptions WU6011.0

Notes:


Subscriptions

• When you subscribe to a topic string with WebSphere MQ you can

specify where you want the messages delivered.

– The queue manager will create a destination, or you can specify your own.

• Your subscription can be durable, or not. – Non-durable subscriptions mean messages are delivered to you only while you

are connected.

– Messages for durable subscriptions are delivered to you when you next collect.

• Subscriptions can be created programmatically or administratively.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 3-10. Two Types of Distributed Publish/Subscribe WU6011.0

Notes:


Two Types of Distributed Publish/Subscribe

• Clustered Pub/Sub – Queue managers are in a cluster. Publications from any queue manager in the

cluster may be subscribed to by any other. In addition, multiple paths caneliminate single points of failure.

• Hierarchical Pub/Sub – Queue managers are arranged in a Parent/Child Hierarchy. – Each Queue manager may have only one Parent. – Queue managers may exchange Pub/Sub information directly between only their

parent or children. – Requiring multiple hops and making single points of failure.

• Plus the composite

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 3-11. Publish/Subscribe in a cluster WU6011.0

Notes:


Publish/Subscribe in a cluster

QM

QM

QM

Pub

Sub

Sub

QM Sub

• Consistent definitions in cluster

• Multiple routes across cluster

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 3-12. Hierarchical Distributed Queue Managers WU6011.0

Notes:


Hierarchical Distributed Queue Managers

QM

QM QM

QM QM QM QMPub Sub

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 3-13. Hierarchical and Clustered Queue Managers WU6011.0

Notes:


Hierarchical and Clustered Queue Managers

QM

QM QM

QM QM

QM

QM

QM

QM

QM

QM

QM

QM

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 3-14. Concepts – Topic String WU6011.0

Notes:


Concepts – Topic String

• A topic string is a nearly unlimited (10,000 characters) length string.

• A topic string “connects” publishers and subscribers.

• A topic string has a “structure” and semantics.

• The structure is supplied by the “/” slash character.

• The semantics are implied by the use of wild cards “#” and ‘+’ in

subscriptions. – An alternative semantics are available for subscriptions which do not use the

structure in topics.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 3-15. Concepts – Topic Object WU6011.0

Notes:


Concepts – Topic Object

• A Topic Object is an MQ object that can be administered.

• Topic Object is named following the same rules as queues and otherMQ objects.

• Topic string (TOPICSTR) is one of the properties of a Topic Object.

• Topic Objects can have other properties set.

• Security can be set on Topic Objects.

• Application programs using the MQI can use the topic object as a full orpartial alternative to topic string when publishing or subscribing.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 3-16. Concepts – Topic Tree WU6011.0

Notes:


Concepts – Topic Tree

• A topic tree is an internalrepresentation of the topic

hierarchy.

• It has a root node at the verytop.

• It is implied from the completeset of topic strings in use --defined, published to,subscribed to.

• There is not necessarily a one-to-one mapping between topicobjects and nodes in the tree.

footballfinance

…

…

football/teams

football/teams/derby

“” (root)

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Nodes which have topic objectsdefined for them can be thought

of as administered nodes.• They are permanent parts of

the hierarchy.

• They can have propertiesspecified for them.

• They have topic object names,which need not reflect the topicstrings.

footballfinance

…

…

football/teams


“” (root)

SYSTEM.BASE.TOPIC

SOCCER

DERBY_TEAM

DEFINE TOPIC(SOCCER) TOPICSTR(‘football’)

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:



• Any missing parts of the

Hierarchy will be “filled in”

when administered nodes are

defined.

• They inherit all properties from

their parent, and so from an

administered node above

them.

footballfinance

…

…

football/teams


“” (root)

SYSTEM.BASE.TOPIC

SOCCER

DERBY_TEAM

football/teamsautomatically added

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Publishing or subscribing to atopic string that is not yet in the

tree causes the tree to beextended.

• These nodes inherit allproperties from their parent,and so from an administerednode above them.

• They are temporary parts ofthe hierarchy and will beremoved when no remainingpublishers or subscribers exist. – A delay (default 1800 seconds)

exists for this

footballfinance

…

…

football/teams


“” (root)

SYSTEM.BASE.TOPIC

SOCCER

DERBY_TEAM

MQSUB(‘/football/teams/chelsea/transfers’)

football/teams/chelsea

football/teams/chelsea/transfers

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:



footballfinance

…

…

football/teams


“” (root)

SYSTEM.BASE.TOPIC

SOCCER

DERBY_TEAMfootball/teams/chelsea

football/teams/chelsea/transfers

Admin node

Non-admin node

• Nodes which have a topic

object associated with them

are known as Administered

Nodes.

• Nodes which were

automatically generated

inherit the properties of the

first Administered Node

above them in the tree

structure.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 3-21. Concepts – Subscription WU6011.0

Notes:


Concepts – Subscription

• A subscription is to a topic string. – We can use wild cards to set them up, but in essence it is to a topic string.

– A topic string corresponds to a node in the topic tree.

• A subscription identifies a destination (queue) which receives a copy of

every publication sent to the topic string.

• A subscription can be durable or non durable.

• A subscription will usually be set up by an application. – But it can be created administratively.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 3-22. Administering Topic Objects WU6011.0

Notes:

The usual MQSC and PCF support will be offered for new commands (for both z/OS and

Distributed platforms)

The exception is that z/OS panels will not be available for those commands which use topic

string attributes since it is not feasible to display this amount of data. Instead, support will

be via a panel from which arbitrary MQSC commands may be entered and their responses

viewed.


Administering Topic Objects

• MQSC commands – DEFINE TOPIC

– DELETE TOPIC – ALTER TOPIC – DISPLAY TOPIC

• PCF commands

• MQ Explorer No z/OS Panels

• Topic objects have usual characteristics of other objects – Associated security – Ability to migrate between releases

– Usual naming rules (48 characters, A-Z, a-z, 0-9, . / _ %)

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 3-23. Topic Objects WU6011.0

Notes:


Topic Objects

• Has a name conforming to usual MQ

rules.

– TOPICSTR – Topic string, up to 10Kcharacters long:

TOPICSTR( ‘/tv/films/horror’ )

– PUB – Whether applications can publish

to this topic:

PUB( ASPARENT | ENABLED |

DISABLED )

– SUB – Whether applications can

subscribe to this topic:SUB( ASPARENT | ENABLED |

DISABLED )

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 3-24. Current Topic Attributes WU6011.0

Notes:

Attributes:

• Cluster -- The name of the cluster to which this topic belongs.

• DEFPRTY(integer) -- The default priority of messages published to the topic.

• DEFPSIST -- Specifies the message persistence to be used when applications specify

the MQPER_PERSISTENCE_AS_TOPIC_DEF option.

• DEFPRESP -- Specifies the put response to be used when applications specify the

MQPMO_RESPONSE_AS_DEF option.

• DESCR(string) -- Plain-text comment. It provides descriptive information about the

object when an operator issues the DISPLAY TOPIC command.

• DURSUB -- Specifies whether applications are permitted to make durable subscriptions

on this topic.


Current Topic Attributes

7/23/2019 WU6011-VU6011STUD


Student Notebook




• MDURMDL(string) -- The name of the model queue to be used for durable

subscriptions that request that the queue manager manages the destination of its

publications.

• MNDURMDL(string) -- The name of the model queue to be used for non-durable

subscriptions that request that the queue manager manages the destination of its

publications.

• NPMSGDLV -- The delivery mechanism for persistent messages published to this

topic:

- ASPARENT -- The delivery mechanism used is based on the setting of the first

parent administrative node found in the topic tree relating to this topic.

- ALL -- Non-persistent messages must be delivered to all subscribers, irrespective of

durability for the MQPUT call to report success.

- ALLAVAIL -- Non-persistent messages are delivered to all subscribers that can

accept the message.

- ALLDUR -- Non-persistent messages must be delivered to all durable subscribers.Failure to deliver a non-persistent message to any non-durable subscribers does not

return an error to the MQPUT call.

• PMSGDLV -- The delivery mechanism for persistent messages published to this topic

(see NMSGDLV).

• PROXYSUB -- Controls whether a proxy subscription can be sent for this topic to

directly connected queue managers, even if no local subscriptions exist.

• PUB – Controls whether messages can be published to this topic.

• PUBSCOPE – Determines whether this queue manager propagates publications toqueue managers as part of a hierarchy or as part of a publish/subscribe cluster.

• SUB – Controls whether applications are to be permitted to subscribe to this topic.

• SUBSCOPE – Determines whether this queue manager subscribes to publications in

this queue manager or in the network of connected queue managers.

• TOPICSTR(string) – The topic string represented by this topic object definition.

• WILDCARD – The behavior of wildcard subscriptions with respect to this topic.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 3-25. Topic Status – current usage of topics WU6011.0

Notes:

Use DISPLAY TPSTATUS to display the status of one or more topic nodes in a topic tree.

The details of this and other new commands will be covered in Unit 7 – New Commands

and MQ Explorer Changes.


Topic Status – current usage of topics

• DISPLAY TPSTATUS( topic-string ) – Topic attributes (TYPE(TOPIC))

• Resolved topic ASPARENT attributes• Number of publishers and subscribers

• Whether a retained publication exists

– Subscriber info (TYPE(SUB)):

• Which subscription IDs are currently subscribed to this topic with associated

connection ID

• Last resume date of subscription and last message delivery time

• Number of messages sent to this subscriber

– Publisher info (TYPE(PUB)):• Which connection IDs are currently publishing to this topic

• Last publish time

• Number of messages published

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 3-26. Administered Subscription WU6011.0

Notes:


Administered Subscription

• Has a name conforming to usual

MQ rules.

• Sample attributes:

– TOPICSTR – Topic string, up to

10K characters long:

TOPICSTR( ‘/entertainment/tv/#’ )

– DEST – Name of object to which

messages for this subscription will

be forwarded:

DEST(MYQ)

– DESTQMGR – Remote queue

manager to which messages are

forwarded:

DESTQMGR(RMT.QMGR)

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 3-27. Durable vs. Non-Durable Subscriptions WU6011.0

Notes:


Durable vs. Non-Durable Subscriptions

• Durable subscriptions – Durability of a subscription indicates whether a subscription remains when the

subscribing application disconnects. – If it does, publications will be available to the application when it connects again.

– Durable subscriptions must have a unique subscription name

• Non-Durable subscriptions – If the subscription is non-durable, then once the application disconnects, the

subscription is removed and no further publications are available to it.

– Non-durable subscriptions can optionally have a unique subscription name.

However, supplying one means your subscription can be more easily identified in

an administrational display.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 3-28. Retained Publications WU6011.0

Notes:


Retained Publications

• Each node on the topic tree can have at most one Retained Publication.

• The retained publication can be requested at any time.

• Whether a publication is a Retained Publication is determined at publish

time by the application program.

• A subscriber can choose to get retained publications every time they are

published.

• In addition a subscriber can request, at anytime, the current retained

publication at a node. – If the subscription contains wildcards many retained pubs from many nodes may

be sent.

• Example: Stock Price. CurrentPrice is a retained publication – I can be notified whenever it changes – ticker tape

– Or can request it at any time

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:




with publications.



commands.




with publications.



commands.


Unit summary

7/23/2019 WU6011-VU6011STUD


Student Notebook




7/23/2019 WU6011-VU6011STUD


Student Notebook



© Copyright IBM Corp. 2008 Unit 4. Publish / Subscribe Security 4-1

5.1

empty Unit 4. Publish / Subscribe Security


This unit describes the implementation of security in a

publish/subscribe environment. Security for topic objects is quitedifferent from security for other WMQ objects. In this unit, we will

highlight those differences and discuss how to best secure your

publications and subscriptions.



• Participate in designing a secure publish/subscribe network

• Understand how publish/subscribe security works

• Distributed implementation using the OAM

• z/OS implementation using SAF

• The subscriber’s destination queue



References


7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Participate in designing a secure publish/subscribe network• Understand how publish/subscribe security works – Distributed implementation using the OAM

– z/OS implementation using SAF

– The subscriber’s destination queue





Unit objectives

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 4-2. WebSphere MQ Publish/Subscribe security WU6011.0

Notes:


WebSphere MQ Publish/Subscribe security

• Publish/Subscribe security is

based on defined topic objects.

– This means you have to define topicobjects where you want to control

security.

– Security is checked from the bottom

up, and MQ tries to find a “positive”

authorization.

””

football hockey

results

romsey

sport

baseball

Def. No auth

Def. Auth

Legend

Not defined

”” is defined as SYSTEM.BASE.TOPIC

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Nodes which have a topic object

associated with them are known

as Admin Nodes.

• Nodes which were automatically

generated inherit the properties

of the first Admin Node above

them in the tree structure.

“”

sport…

sport/football/players

sport/football/players/romsey

Admin node

…

sport/football/players/romsey/transfers

sport/football/players/romsey/transfers/2006

Non-admin node

…

Inherits

Root

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:


“”

…

Admin node

…

Non-admin node

…

Root

sport






ST

APP AMQSUB

• Admin Nodes are also used to

determine whether a user has

authority to a node in the topictree.

• Example: – User A running App A wants to

subscribe to topic

sport/football/players/

romsey/transfers/2006

– Admin Node “” does not allow

User A to subscribe, so access is

denied

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:






• Example: – User A wants to subscribe to topic



– Admin Node


allows User A to subscribe, so

access is granted

“”

…

Admin node

…

Non-admin node

…

Root

sport




sport/football/players/romsey/transfers/2006 APP AMQSUB

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:






• Example: – User A wants to subscribe to topic



– Admin Node


does not allow User A to

subscribe, but the admin node

/sport does, so access is granted

– Once permitted at an ADMIN node

you cannot be denied further downthe tree

“”

…

Admin node

…

Non-admin node

…

APP AMQSUB

Root

sport




It is important from both anadministration and security point ofview to ensure that your trees arestructured to align with how yoursubscriptions are made.


7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:






• Example: – User B wants to subscribe to topic


– The Admin Node sport does not

allow User B to subscribe, so

access is denied

“”

…

Admin node

…

Non-admin node

… APP BMQSUB

Root

sport





ST

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 4-8. Security WU6011.0

Notes:

Generic profiles (using the asterisk as a wildcard) were introduced for distributed systems

in MQ version 5.3.


Security

• When you define topics, remember that MQ can use genericprofiles.

• So instead of defining topic objects like: – SPORT_FOOTBALL_RESULTS – SPORT_FOOTBALL_PLAYERS_HURSLEY

• It might be a good idea to do it like this: – SPORT.FOOTBALL.RESULTS – SPORT.FOOTBALL.PLAYERS.HURSLEY

• This allows you to grant access like this: – setmqaut –n SPORT.FOOTBALL.* . . .

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 4-9. Externals – Topic security WU6011.0

Notes:


Externals – Topic security

• Security in the API – When publishing, a check is performed at the MQOPEN of the topic

you wish to publish to.• No check carried out for actual put to subscribers at publish time

(that is carried out at subscribe time).

– When subscribing, a check is carried out when an MQSUB to thespecified topic is received.• Subscriber must also have authority to put to the destination queue

for the subscription – actual ‘publish’ check.• Managed

– Access to the system generated temp queue

• Non-managed – You supply the queue.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 4-10. Controlling security using MQ Explorer (1 of 5) WU6011.0

Notes:


Controlling security using MQ Explorer (1 of 5)

• You select TOPICS and open Manage Authority Records.

* This is not supported on z/OS

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Now you can see which groups are have access to the topic.

• We have only the mqm group; which is the default.


7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:



• Grant Authority to FINANCE group for the MONEY topic.


7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Now fill in the group

name in the Entity

Name field.

• Select the appropriate

authorities.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:



• Now we just check that the authorizations are correct and what

we expected.

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 4-16. Check TOPIC security with MQ Explorer (1 of 3) WU6011.0

Notes:


Check TOPIC security with MQ Explorer (1 of 3)

• Click on Find Accumulated Authorities…

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 4-17. Check TOPIC security with MQ Explorer (2 of 3) WU6011.0

Notes:


Check TOPIC security with MQ Explorer (2 of 3)

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 4-19. Controlling security using SAF WU6011.0

Notes:


Controlling security using SAF

• We use the class MXTOPIC.• First define the topic profile

– RDEFINE MXTOPIC WMQ7.SUBSCRIBE.SPORT UACC(NONE)

• Now give group access to the topic. – PERMIT WMQ7.SUBSCRIBE.SPORT CLASS(MXTOPIC) ID(GROUP)

ACC(ALTER)

• We can use generic profiles with caution: – PERMIT WMQ7.SUBSCRIBE.SPORT.** CLASS(MXTOPIC) ID(GROUP)

ACC(ALTER)

– This protects all SPORT.* topics.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 4-20. Controlling security using SAF WU6011.0

Notes:

Why does it say SUBSCRIBE? It’s because we also have a PUBLISH profile.


• You will see the ICH408I messages in your z/OS logs.

• But the security adminstrator should not just add anyone in thebase profile hlq.SUBSCRIBE.SYSTEM.BASE.TOPIC. This wouldactually switch the topic security off for that user or group of users.

Controlling security using SAF

ICH408I USER(USER2 ) ...

hlq.SUBSCRIBE.SPORT.FOOTBALL ...

ICH408I USER(USER2 ) ...

hlq.SUBSCRIBE.SYSTEM.BASE.TOPIC ...

ST

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 4-21. Subscription security with SAF WU6011.0

Notes:


Subscription security with SAF

UPDATEMQSO_ALTERNATE_USER

RACF access required to

hlq.ALTERNATE.USER.alternateuserid profile

in MQADMIN or MXADMIN class

UPDATEMQSO_CREATE and MQSO_ALTER


hlq.CONTEXT.queuename profile in

MQADMIN or MXADMIN class if you are

setting any of the identity context fields in theMQSD

UPDATEMQSO_CREATE , MQSO_ALTER and

MQSO_RESUME

RACF access required to hlq.queuename

profile in MQQUEUE or MXQUEUE class

MQSUB – additional authority to non managed

destination queues

READMQSO_RESUME

ALTERMQSO_CREATE and MQSO_ALTER


hlq.SUBSCRIBE.topicname profile in

MXTOPIC class

MQSUB to a topic

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 4-22. Close Subscription security with SAF WU6011.0

Notes:


Close Subscription security with SAF

UPDATEMQCO_REMOVE_SUB

RACF access required tohlq.SUBSCRIBE.topicname profile in

MXTOPIC class

MQCLOSE ( of a subscription)

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 4-23. Publish security with SAF WU6011.0

Notes:


Publish security with SAF

UPDATEMQOO_OUTPUT or MQPUT1


hlq.queuename profile in MQQUEUE

or MXQUEUE class for the alias

queue

MQOPEN (Alias Q-> topic)

UPDATEMQOO_OUTPUT or MQPUT1

RACF access required tohlq.PUBLISH.topicname profile in

MXTOPIC class

MQOPEN ( of a topic)

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 4-24. What happens if...? WU6011.0

Notes:


What happens if...?

• What happens if we grant access

to ”” ?

– SYSTEM.BASE.TOPIC

””

football hockey

results

romsey

sport

baseball

Def. No auth

Def. Auth

Legend

Not defined

””

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 4-25. What happens if...? WU6011.0

Notes:


What happens if...?

• What happens if we grant access

to ”” ?

– SYSTEM.BASE.TOPIC

• Everyone gets authority to

everything, because of the way

the security works.

””

football hockey

results

romsey

sport

baseball

Def. No auth

Def. Auth

Legend

Not defined

””

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 4-26. What if we rearrange the tree? WU6011.0

Notes:

We want assure that only members of the resultpub group are allowed to publish football

results room. Our original tree design had the results above the team name.

Could we have designed the tree in another way? We could also place the results below

the team name within the tree.

How will that effect the authorizations?

1. We have created new topics as shown.

2. We use a generic profile to protect the results.

3. We need to assure that the publication on higher level is protected to prevent anyone

from publishing there, due to the inherence of authorization.

a. Remember we cannot add a ‘DENY’ authorization.

b. So if we give the resultpub group access to publish on the hursley level, they would

also be allowed to publish to the results.


What if we rearrange the tree?

• We have seen how to protect

results information before.

• Created topics: – SP.FO.HURSLEY.RES

– SP.FO.ROMSEY.RES

• setmqaut: – -n SP.FO.*.RES

Def. No auth

Def. Auth

Legend

Not defined

””

football hockey

romsey

results

sport

baseball

hursley

results

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 4-27. The message is: Think, Plan and Test WU6011.0

Notes:

As we just have seen, it’s a non trivial job to design pub/sub security. You need to have a

good plan if you need to protect certain branches in the topic tree.

There is no great difference in the way pub/sub security is handled compared to normal

MQ Security, except that we have to create TOPIC objects to protect the topic strings.


The message is: Think, Plan and Test

””

football hockey

romsey

results

sport

baseball

hursley

results

Def. No auth

Def. Auth

Legend

Not defined

””

football hockey

results

romsey

sport

baseball

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 4-28. The message is: Think, Plan and Test WU6011.0

Notes:


The message is: Think, Plan and Test

• MQ publish/subscribe security can be a challenge to

implement and control. – By using the topics you can change the security configuration without

actually changing the publish/subscribe tree structure.

– We advise that a simple and manageable structure be used.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 4-29. Pub/Sub Security – MQ vs. Message Broker WU6011.0

Notes:


Pub/Sub Security – MQ vs. Message Broker

• MQ publish/subscribe uses setmqaut with the topic type. – We can only grant positive access, not deny access to an object.

– Distributed security administration

• Message Broker can use User Name Server: – Grant access to a topic.

– Deny access to a topic.

– Cetralized security administration

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 4-30. Basic MQ security on Pub/sub queues WU6011.0

Notes:


Basic MQ security on Pub/sub queues

• MQ Pub/sub uses normal MQ queues, and when subscribing

you need to have access to the ”reply” queue.

• When using managed subscriptions, you need access to: – SYSTEM.NDURABLE.MODEL.QUEUE

– SYSTEM.DURABLE.MODEL.QUEUE

• You also need connect access to the queue manager.

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:










Unit summary

7/23/2019 WU6011-VU6011STUD


Student Notebook



© Copyright IBM Corp. 2008 Unit 5. Publish/Subscribe with the MQ API 5-1

5.1

empty Unit 5. Publish/Subscribe with the MQ API


This unit describes the new API programming capabilities added to

IBM WebSphere MQ Version 7 to allow native publish and subscribe.We will look at the two new MQI calls, MQSUB and MQSUBRQ, two

new structures, and changes to existing calls and structures.



• Publish using the MQI

• Subscribe using the MQI

• Understand the different ways to subscribe to publications

• Use the new variable string data type in MQI applications



References


7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Publish using the MQI• Subscribe using the MQI




• Publish using the MQI• Subscribe using the MQI



Unit objectives

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 5-2. Introduction WU6011.0

Notes:

There used to be 13 MQI calls; now there are 26. We will be talking about two of them in

this unit, MQSUB and MQSUBRQ. The rest of the new calls will be covered later in this

course.


Introduction

• In WebSphere MQ V7:

– New verbs allow MQI applications to easily performpublish/subscribe.

– Publications and subscriptions can be handled by both MQI

and JMS applications.

– Publish/subscribe functionality is now available on z/OS

without needing Message Broker.

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 5-4. Publication explanation WU6011.0

Notes:


Publication explanation

• Publication is MQPUT to a topic string

• Topic string can be created in three ways – Pre-defined topic object

• DEFINE TOPIC(SOCCER) TOPICSTR(‘football’)

– Dynamic topic string

– Dynamic topic string partially pre-defined

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 5-5. Publishing applications WU6011.0

Notes:


Publishing applications

Publishing AppPublishing App

L

o c a l Q M g r

• Connect to the queue

manager

MQCONN(MyQmgr,Hconn,CC,RC )

Set up MQOD and Open OptionsSet up MQOD and Open Options

Set up MQPMOSet up MQPMO

MQOPEN(Hconn,OD,OpenOpts,Hobj,CC,RC)

• Open a topic

MQPUT(Hconn,Hobj,MD,PMO,

BuffLen,Buffer,CC,RC ) • Put publications to thattopic

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 5-6. Set up MQOD and open options WU6011.0

Notes:


Set up MQOD and open options

sports/football/hursley/results

Publishing AppPublishing App

ObjDesc.ObjectString.VSPtr =“sports/football/hursley

/results”;

DEF TOPIC(MY.TOPIC)TOPICSTR(sports/football/hursley/results)

ObjDesc.Version = MQOD_VERSION_4

ObjDesc.ObjectType = MQOT_TOPIC;

strncpy(ObjDesc.ObjectName,“MY.TOPIC”, MQ_TOPIC_NAME_LENGTH);

2

1

3 DEF TOPIC(MY.ROOT)TOPICSTR(sports/football/hursley)

strncpy(ObjDesc.ObjectName,“MY.ROOT”, MQ_TOPIC_NAME_LENGTH);ObjDesc.ObjectString.VSPtr

= “results”;

OpenOpts = MQOO_OUTPUT; • Open for output

• Object type

• Fill in topic or topicstring

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 5-7. MQOD C declaration with new fields WU6011.0

Notes:


MQOD C declaration with new fields

typedef struct tagMQOD MQOD;

struct tagMQOD {

MQCHAR4 StrucId; /* Structure identifier */ MQLONG Version; /* Structure version number */

MQLONG ObjectType; /* Object type */

MQCHAR48 ObjectName; /* Object name */

MQCHAR48 ObjectQMgrName; /* Object queue manager name */

MQCHAR48 DynamicQName; /* Dynamic queue name */

MQCHAR12 AlternateUserId; /* Alternate user identifier */

/* Ver:1 */

MQLONG RecsPresent; /* Number of object records present */

MQLONG KnownDestCount; /* Number of local queues opened successfully */

MQLONG UnknownDestCount; /* Number of remote queues opened successfully */

MQLONG InvalidDestCount; /* Number of queues that failed to open */

MQLONG ObjectRecOffset; /* Offset of object recd from start of MQOD */

MQLONG ResponseRecOffset; /* Offset of response recd from start of MQOD */

MQPTR ObjectRecPtr; /* Address of first object record */

MQPTR ResponseRecPtr; /* Address of first response record */

/* Ver:2 */

MQBYTE40 AlternateSecurityId; /* Alternate security identifier */

MQCHAR48 ResolvedQName; /* Resolved queue name */

MQCHAR48 ResolvedQMgrName; /* Resolved queue manager name */

/* Ver:3 */

MQCHARV ObjectString; /* Object Long name */

MQCHARV SelectionString; /* Message Selector */

MQCHARV ResObjectString; /* Resolved Long object name*/

/* Ver:4 */ };

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 5-8. Set up MQPMO WU6011.0

Notes:


Set up MQPMO

• MQPMO_RETAIN – The publication being sent is to be retained by the queue manager. This allows a

subscriber to also request a copy of this publication after the time it waspublished, by using the MQSUBRQ call. – No more than one publication will be retained at each node of the topic tree.

• MQPMO_SUPPRESS_REPLYTO – ReplyToQ and ReplyToQMgr fields will not be passed on to the subscribers.

• MQPMO_SCOPE_QMGR – Publications will not be forwarded to any remote publish / subscribe queue

manager.

• MQPMO_NOT_OWN_SUBS – The application does not want to send any of its publications to subscriptions itowns. Subscriptions are considered to be owned by the same application if theconnection handles are the same.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 5-9. Subscription explanation WU6011.0

Notes:


Subscription explanation

• Subscription choices

– Non-durable subscription - subscribe, receive pubs, and unsubscribe

in a single program

– Durable subscription – subscribe, go away, return later to retrieve

publications

• Return to the subscription based on the unique subscription name.

– Subscription request – request immediate receipt of the current

retained message for the topic string

• Subscription request call can happen within a durable or non-

durable subscription

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 5-10. New API call for subscription registration WU6011.0

Notes:


New API call for subscription registration

• MQSUB – register subscription

– Hconn – connection handle

– SubDesc – MQSD – subscription description structure

– Hobj – object handle from destination queue

– Hsub – object handle returned for subscription

– CompCode – completion code

– Reason – reason code

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty If ResObjectString is specified incorrectly, as per the description of how to use the

MQCHARV structure then the call will fail with reason code

MQRC_RES_OBJECT_STRING_ERROR.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 5-12. Non-durable subscription application WU6011.0

Notes:


Non-durable subscription application

Subscribing AppSubscribing App

L o c a l Q M g r

• Connect to a queue manager MQCONN(MyQmgr,Hconn,CC,RC)

Set up MQSDSet up MQSD

MQSUB(Hconn,SD,Hobj,Hsub,CC,RC)

• Subscribe to a topic

MQGET(Hconn,Hobj,MD,GMO,BuffLen,Buffer,DataLength,CC,RC)

• Get publications published to

that topic

MQCLOSE(Hconn,Hsub,CloseSubOpts,CC,RC)

MQCLOSE(Hconn,Hobj,CloseOpts,CC,RC)

• Close subscription to

unsubscribe

• Close queue

Set up Close OptionsSet up Close Options

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 5-13. Set up MQSD – subscription description WU6011.0

Notes:


Set up MQSD – subscription description


MQSUB(Hconn,SD,CC,RC)

• Fill in topic object name SubDesc.ObjectName =“SPORTS.RESULTS”;

Topic Object: SPORTS.RESULTS

• Choose to Create, Resume or Alter a

subscriptionSubDesc.Options = MQSO_CREATE

| MQSO_MANAGED

| MQSO_NON_DURABLE

| MQSO_FAIL_IF_QUIESCING;• Choose for the queue manager tocreate the queue

Hobj,Hsub,

• Select durability

• Any other options

– Call returns you a subscription handle.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 5-14. Durable subscription application WU6011.0

Notes:


Durable subscription application


L o c a l Q M g r




• Subscribe to a topic

MQGET(Hconn,Hobj,MD,GMO,BuffLen,Buffer,

DataLength,CC,RC)


that topic



• Close subscription with

MQCO_KEEP_SUB

• Close queue


MQOPEN(Hconn,OD,OpenOpts,Hobj,CC,RC)• (Optionally) open a destination

queue

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 5-15. Set up MQSD – subscription description WU6011.0

Notes:


Set up MQSD – subscription description


MQSUB(Hconn,SD,CC,RC)

• Fill in topic stringSubDesc.ObjectString.VSPtr =“sports/football/results/#”;

Topic String: sports/football/results/#

SubDesc.SubName.VSPtr =“MoragsSub”;

• Fill in subscription name

• Choose to Create, Resume or Alter a

subscriptionSubDesc.Options = MQSO_CREATE

| MQSO_NEW_PUBLICATIONS_ONLY

| MQSO_DURABLE

| MQSO_FAIL_IF_QUIESCING;• Choose not to receive retainedpublications

Hobj,Hsub,

• Select durability

• Any other options

– Call returns you a subscription handle.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 5-16. Return to the durable subscription WU6011.0

Notes:


Return to the durable subscription


L o c a l Q M g r



MQSUB(Hconn,SD,Hobj,HsubCC,RC)

• Subscribe to same topic with

MQSO_RESUME

MQGET(Hconn,Hobj,MD,GMO,BuffLen,Buffer,

DataLength,CC,RC)

• Get all publications from that

topic since last connection



• Close subscription with

MQCO_REMOVE_SUB

• Close queue


MQOPEN(Hconn,OD,OpenOpts,Hobj,CC,RC)• (Optionally) open a destination

queue

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 5-17. MQSD -- subscription options WU6011.0

Notes:


MQSD -- subscription options

• Mandatory Choice – MQSO_CREATE for a new subscription

– MQSO_RESUME to continue existing subscription by name – MQSO_ALTER to change existing subscription by name

• You can combine options – MQSO_CREATE + MQSO_RESUME

• Create if it doesn’t exist

• Resume if it does exist

– MQSO_CREATE + MQSO_ALTER

• Create if it doesn’t exist

• Alter if it does exist

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 5-18. MQSD – special subscription options WU6011.0

Notes:


MQSD – special subscription options

• Durability Options – MQSO_DURABLE for a subscription that will last beyond the end of the

application connection – MQSO_NON_DURABLE for a subscription that ends with the close of the

subscription

• Destination Options – MQSO_MANAGED if you want the queue manager to create and manage the

queue where the publications will be stored

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 5-19. MQSD – more subscription options WU6011.0

Notes:

MQSO_SCOPE_QMGR

This subscription is made only on the local queue manager, and will not be propagated to

any adjacent queue managers. The MQSO_SCOPE_QMGR will override

SUBSCOPE(ALL)

MQSO_NEW_PUBLICATIONS_ONLY

No currently retained publications are to be sent, when this subscription is created, only

new publications. This option only applies when MQSO_CREATE is specified. Any

subsequent changes to a subscription do not alter the flow of publications and so any

publications that have been retained on a topic, will have already been sent to the

subscriber as new publications.

If this option is specified without MQSO_CREATE it will cause the call to fail with

MQRC_OPTIONS_ERROR. On return from an MQSUB call using MQSO_RESUME this

option will not be set even if the subscription was created using this option.


MQSD – more subscription options

• MQSO_SCOPE_QMGR – this subscription is made only on the localqueue manager

• MQSO_NEW_PUBLICATIONS_ONLY – only receive new publications,not previously created retained publications

• MQSO_PUBLICATIONS_ON_REQUEST – only receive retainedpublications using MQSUBRQ, no new publications

• MQSO_WILDCARD_TOPIC – wildcards are specified with thecharacters # and + and represent 1 or more topic elements

• MQSO_WILDCARD_CHAR – wildcards are specified with thecharacters * and ? and represent 1 or more characters

7/23/2019 WU6011-VU6011STUD


Student Notebook




If this option is not used, previously retained messages will be sent to the destination

queue provided. If this action fails due to an error, either

MQRC_RETAINED_MSG_Q_ERROR or MQRC_RETAINED_NOT_DELIVERED, the

creation of the subscription will fail.

This option is not valid in combination with MQSO_PUBLICATIONS_ON_REQUEST.

MQSO_PUBLICATIONS_ON_REQUEST

Setting this option indicates that the subscriber will request information specifically when

required. The queue manager will not to send unsolicited messages to the subscriber. The

retained publication (or possibly multiple publications if a wildcard is specified in the topic)

will be sent to the subscriber each time a MQSUBRQ call is made using the Hsub handle

from a previous MQSUB call. No publications will be sent as a result of the MQSUB call

using this option. On return from an MQSUB call using MQSO_RESUME this option will be

set if appropriate.

This option is not valid in combination with MQSO_NEW_PUBLICATIONS_ONLY.

MQSO_WILDCARD_CHARWildcards only operate on characters within the topic string.

The behavior defined by MQSO_WILDCARD_CHAR is shown in the table below.

Special CharacterBehavior

/No significance, just another character

*Wildcard, zero or more characters

?Wildcard, one character

%Escape character to allow the characters ‘*’, ‘?’ or ‘%’ to be used in a string and not beinterpreted as a special character, for example, ‘%*’, ‘%?’ or ‘%%’.

To illustrate this, the following example is used.

Publishing on the following topic

/level0/level1/level2/level3/level4

will match subscribers using the following topic

*

/* /level0/level1/level2/level3/*

/level0/level1/*/level3/level4

/level0/level1/level2/level3/level4

Note: This use of wildcards supplies exactly the meaning provided in WebSphere MQ V6

and WebSphere MB V6 when using MQRFH1 formatted messages for Publish/Subscribe.

It is recommended that this is not used for newly written applications and is only used for

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 5-20. MQSD – other subscription options WU6011.0

Notes:

MQSO_GROUP_SUB

This subscription is to be grouped with other subscriptions of the same SubLevel using the

same queue and specifying the same correlation ID so that any publications to topics that

would cause more than one publication message to be provided to the group of

subscriptions, due to an overlapping set of topic strings being used, only causes one

message to be delivered to the queue. If this option is not used, then each unique

subscription (identified by SubName) that matches is provided with a copy of the

publication which could mean more than one copy of the publication may be placed on thequeue shared by a number of subscriptions.

Only the most significant subscription in the group is provided with a copy of the

publication. The most significant subscription is based on the Full topic name up to the

point where a wildcard is found. If a mixture of wildcard schemes is used within the group,

only the position of the wildcard is important. You are advised not to combine different

wildcard schemes within a group of subscriptions that share the same queue.


MQSD – other subscription options

• MQSO_GROUP_SUB – group together subscriptions of the sameSublevel on the same queue, to cause a single publication to be sent to

the queue

• MQSO_ANY_USERID – user of subscription is not limited to a singleuserid

• MQSO_FIXED_USERID – subscription can only be altered or resumedby the last userid to create or alter – the default

• MQSO_SET_CORREL_ID

• MQSO_SET_IDENTITY_CONTEXT• MQSO_ALTERNATE_USER_AUTHORITY

• MQSO_FAIL_IF_QUIESCING

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




Do not specify both MQSO_ANY_USERID and MQSO_FIXED_USERID. If neither is

specified, the default is MQSO_FIXED_USERID.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 5-21. Set up Close Options WU6011.0

Notes:


Set up Close Options

• MQCO_KEEP_SUB – Subscription is kept

– Only valid for durable – Default for durable

• MQCO_REMOVE_SUB – Subscription is closed

– Any publications not yet consumed from a managed destination are removed

when both the subscription is removed and the object handle for the managed

destination is closed

– Default for non-durable

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 5-22. Publications on Request Only WU6011.0

Notes:


Publications on Request Only


L

o c a l Q M g r

• Connect to the queue manager MQCONN(MyQmgr,Hconn,CC,RC)



• Subscribe to a topic using

MQSO_PUBLICATIONS_ON_

REQUEST

MQGET(Hconn,Hobj,MD,GMO,BuffLen,Buffer,DataLength,CC,RC)


that topic

MQSUBRQ(Hconn,Hsub,SRO,CC,RC )• Request a retained publication

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 5-23. New API call for subscription requests WU6011.0

Notes:

Action Description: This parameter controls the particular action that is being requested

on the subscription. One (and only one) of the following must be specified:

MQSR_ACTION_PUBLICATION

This action requests an update publication be sent for the specified topic. This is normally

used if the subscriber specified the option MQSO_PUBLICATIONS_ON_REQUEST on the

MQSUB call when it made the subscription. If the queue manager has a retained

publication for the topic, this is sent to the subscriber. If not, the call fails. If an application is

sent a publication which was retained, this will be indicated by the MQIsRetained messageproperty of that publication.

Since the topic in the existing subscription represented by the Hsub parameter may contain

wildcards, the subscriber might receive multiple retained publications.


New API call for subscription requests

• MQSUBRQ – subscription request options

– Hconn – connection handle

– Hsub – subscription handle

– Action – action requested on this subscription• MQSR_ACTION_PUBLICATION

– SubRqOpts – MQSRO – subscription request options

– CompCode – completion code

– Reason – reason code

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 5-24. New structure for MQSUBRQ WU6011.0

Notes:


New structure for MQSUBRQ

• MQSRO – subscription request options

– StrucId – structure identifier

– Version – structure version number

– Options – options• MQSRO_FAIL_IF_QUIESCING

• MQSRO_NONE

– NumPubs – number of publications returned

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 5-25. Publish/Subscribe using MQI - Summary WU6011.0

Notes:


Publish/Subscribe using MQI - Summary

• The verbs used are:- – MQOPEN

– MQPUT – MQSUB

– MQSUBRQ

– MQCLOSE

• New structures to accompany new verbs – MQSUB – MQSD – Subscription Descriptor

– MQSUBRQ – MQSRO – Subscription Request Options

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 5-27. Variable length string - MQCHARV WU6011.0

Notes:


Variable length string - MQCHARV

• New data type used for publish/subscribe in MQ structures

– MQOD• ObjectString

• ResObjectString

• SelectionString

– MQSD• ObjectString

• ResObjectString

• SubUserData

• SubName

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook



© Copyright IBM Corp. 2008 Unit 6. Other MQI Enhancements 6-1

5.1

empty Unit 6. Other MQI Enhancements


This unit describes three of the new programming facilities of

WebSphere MQ Version 7 -- message properties and their use asselectors, message handles, and message tokens. Message handles

can be used by MQI applications to create, change and delete

message properties. Message tokens allow applications to

cooperatively browse the messages on a queue.



• Understand how message properties are viewed by the MQ API • Use a message handle to inquire, set and delete message

properties

• Understand message selectors, and their use in both traditional

and publish/subscribe applications

• Understand the concept of browsing a queue using message

tokens

• See the advantages of using asynchronous consume


• Class discussion and lab exercises

References


7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Understand how message properties are viewed by the MQ API

• Use a message handle to inquire, set and delete message

properties

• Understand message selectors, and their use in both

traditional and publish/subscribe applications


tokens





properties




tokens


Unit objectives

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-2. WebSphere MQ V7 Message WU6011.0

Notes:

In Unit 2 – Enhanced JMS, we looked at the layout of a JMS message. How do the parts of

a JMS message compare to those in an MQ message?

Header In WebSphere MQ, the header for a message is the message descriptor (MQMD).

All messages must begin with this header.

Properties WebSphere MQ has used the concept of message properties since the first

use of JMS applications in MQ. Now in Version 7, MQI applications will be able to access

and manipulate those same message properties.

Body The body of a WebSphere MQ message is the traditional data portion of that

message.


WebSphere MQ V7 Message

Message Descriptor

Message Properties

Data

• Used to identify messages

• All messages support the same set ofheader fields

• Used to add optional header fields to a

message

• Categories• JMS optional header fields

• Application-specific properties

• Provider-specific properties

• Actual message data to be delivered

• Data is any string of bytes meaningfulto its application program

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-3. Message properties in V7 WU6011.0

Notes:


Message properties in V7

• Message properties can be handled natively in MQI. – Applications can get message properties after an MQGET and set

message properties before an MQPUT.

– Prior to V7, only JMS applications could handle message properties.

• Message properties are in a format of name-value pairs. – <Property Name> <Value>

– For example, <hometeam> <hursley>

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-4. MQMD properties WU6011.0

Notes:


MQMD properties

• Fields in the message descriptor can also be handled as

message properties. – JMS_IBM_MQMD_<Field> as the message property name, where

<Field> is the C language declaration for the MQMD field name

– For example, JMS_IBM_MQMD_MsgType

– StrucId and Version fields are not available as message properties

• Segmented messages can not contain any message

properties other than the MQMD.

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty CompCode – completion code

Reason – reason code

MQCMHO – create message handle options structure

StrucId – structure id

Version – structure version number

Options - MQCMHO_VALIDATE – validate the property name

MQCMHO_DEFAULT_VALIDATION – same as validate (may be changed in future

releases)

MQCMHO_NO_VALIDATION – do not validate the property name

MQCMHO_NONE – default validation with no other options (for documentation purposes)

The application does not need to provide an MQMD structure provided that a valid

message handle is supplied in the MsgHandle field of the MQGMO structure or the

Original/NewMsgHandle fields of the MQPMO structure. If nothing is provided in this field,

the descriptor of the message will be taken from the one associated with the message

handle/s.

<MQGET specifically>

If MQGMO_PROPERTIES_FORCE_MQRFH2 is specified, or the

MQGMO_PROPERTIES_AS_Q_DEF is specified and the PropertyControl queue attribute

is MQPROP_FORCE_MQRFH2 then the call fails with reason code MQRC_MD_ERROR.

If match options are specified and the message descriptor associated with the message

handle is being used then the input fields used for matching come from the message

handle.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-8. Inquire message properties WU6011.0

Notes:

MQINQMP (Hconn, Hmsg, InqPropOpts, Name, PropDesc, Type, ValueLength, Value,

DataLength, CompCode, Reason)

Hconn – connection handle

Hmsg – message handle

InqPropOps (MQIMPO structure) – inquire message property options

Name – name of the message property

PropDesc (MQPD structure) – message property descriptor structure

Type – the type of the message property, e.g. Boolean, integer, string, etc.

ValueLength – length in bytes of the value area

Value – value of the message property

DataLength – length in bytes of the actual property value returned to the application

CompCode – completion code


Inquire message properties

• MQINQMP inquires a property of a message specified by its

handle. – A message descriptor field or

– An actual message property

• MQINQMP can be used to iterate over a subset/all the

properties in a message.

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-9. Set message properties WU6011.0

Notes:

MQSETMP (Hconn, Hmsg, SetPropOpts, Name, PropDesc, Type, ValueLength, Value,

CompCode, Reason)

Hconn – connection handle

Hmsg – message handle, returned by a previous MQCRTMH call

SetPropsOpts (MQSMPO structure) – controls how message properties are set

Name – the name of the property to set

PropDesc (MQPD structure) – message property descriptor structure

Type – the type of the message property, e.g. Boolean, integer, string, etc.

ValueLength – length in bytes of the property value in the Value parameter

Value -- the value of the property to be set

CompCode – completion code

Reason -- reason code


Set message properties

• MQSETMP sets a property of a message specified by its

handle. – A message descriptor field or

– An actual message property

• MQSETMP can be used to set both application and IBM-

defined message properties.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-10. Message properties compatibility WU6011.0

Notes:


Message properties compatibility

• Other message property-related calls – MQDLTMH deletes a message handle and is the inverse of the MQCRTMH call.

– MQDLTMP allows an application to delete a property (or reset a message

descriptor field to its default value) of a message specified by its handle and is the

inverse of the MQSETMP call.

– MQMHBUF produces a representation of the message handle in a buffer.

– MQBUFMH produces a message handle from a message descriptor and buffer.

– MQBUFMH and MQMHBUF are the least likely calls to be used, but are provided

for advanced users, especially vendors.

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:

PROPCTL – Queue property control attribute.

This parameter is applicable to Local, Alias and Model queues. This parameter is

optional.

Permitted values are:

ALL

All properties of the message are included with the message when it is sent to the

remote queue manager. The properties, except those in the message descriptor (orextension), are placed in one or more MQRFH2 headers in the message data.

COMPAT

If the message contains a property with a prefix of mcd., jms., usr. or mqext., all

message properties are delivered to the application in an MQRFH2 header.

Otherwise all properties of the message, except those contained in the message

descriptor (or extension), are discarded and are no longer accessible to the

application.



• New queue parameter PROPCTL determines how message properties

are delivered to getting applications

– COMPAT – all message properties prefixed by mcd., jms., usr., or mqext. will bedelivered in MQRFH2. All other message properties are discarded. This is the

default.

– ALL – all message properties included in one or more MQRFH2 headers.

– FORCE – message properties are always returned in MQRFH2 header,

regardless of whether the application specifies a message handle. Properties will

not be accessible by message handle.

– NONE – all message properties are removed from the message.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty This is the default value; it allows applications which expect JMS related properties

to be in an MQRFH2 header in the message data to continue to work unmodified.

FORCE

Properties are always returned in the message data in an MQRFH2 header

regardless of whether the application specifies a message handle.

A valid message handle supplied in the MsgHandle field of the MQGMO structureon the MQGET call is ignored. Properties of the message are not accessible via the

message handle.

NONE

All properties of the message, except those in the message descriptor (or

extension), are removed from the message before the message is sent to the

remote queue manager.

Note, that for a transmission queue, which is a local queue with USAGE(XMITQ), the

PROPCTL attribute of the queue is irrelevant and it is the PROPCTL attribute on the

corresponding channel object that controls the message property behavior.

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:

PROPCTL – Channel property control attribute.

This parameter is applicable to Sender, Server, Cluster Sender and Cluster Receiver

channels. This parameter is optional.

Permitted values are:

ALL

All properties of the message are included with the message when it is sent to the

remote queue manager. The properties, except those in the message descriptor (orextension), are placed in one or more MQRFH2 headers in the message data.

COMPAT

If the message contains a property with a prefix of mcd., jms., usr. or mqext., all

message properties are delivered to the application in an MQRFH2 header.

Otherwise all properties of the message, except those contained in the message

descriptor (or extension), are discarded and are no longer accessible to the

application.



• New channel parameter PROPCTL determines if message properties

will be sent to pre-V7 queue manager

– ALL – all properties of the message are included with the message when it is sentto the remote queue manager.

– COMPAT – if the message contains a property with a prefix of mcd., jms., usr. or

mqext., all message properties are delivered to the application in an MQRFH2

header. Otherwise all properties of the message, except those contained in the

message descriptor (or extension), are discarded and are no longer accessible to

the application. This is the default value.

– NONE – all properties of the message, except those in the message descriptor (or

extension), are removed from the message before the message is sent to theremote queue manager.

• Sender, Server, Cluster Sender and Cluster Receiver channels only

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty This is the default value; it allows applications which expect JMS related properties

to be in an MQRFH2 header in the message data to continue to work unmodified.

NONE

All properties of the message, except those in the message descriptor (or

extension), are removed from the message before the message is sent to the

remote queue manager.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-13. What is a message selector? WU6011.0

Notes:


What is a message selector?

• A message selector is a variable-length string, containing an

SQL92 query.

• It is used by an application to choose only those messages

whose message properties satisfy that query.

• For example, a message selector “sport = football” could be

used to only select messages from a queue where the

message property “sport” was equal to the value “football”.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-14. In MQ Version 7 WU6011.0

Notes:


In MQ Version 7

• Selection process takes place on the server side. – Leading to greater network efficiency in client scenarios

• Message selectors can be used by JMS, XMS and MQI

applications.

• API applications can now select on any field in the message

properties or the message descriptor.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-15. Selector syntax WU6011.0

Notes:

• String literals should be enclosed within single quotes (‘) and may contain any

sequence of bytes, up until the terminating single quote.

• Byte strings may be used in a selection string by using pairs of hex characters which

together represent each byte in the byte string. The byte string should be enclosed

within double quotes and prefixed with “0x” (upper/lowercase ‘x’ permitted).

The length of the byte string should be a multiple of two and at least one byte should be

described. Matching a selector byte string to a message property of type

MQTYPE_BYTE_STRING is performed without any special action taken on leading/trailingnulls, that is, they are treated as just another character. Endianness is also not considered.

The length of both selector and property byte strings should therefore be equal and the

sequence of bytes should be exactly the same.

• An exact numeric literal is a numeric value without a decimal point, such as 57, -957,

+62; numbers in the range of -9,223,372,036,854,775,808 to

9,223,372,036,854,775,807 are supported and are internally stored as signed long

values. Exact numeric literals may be represented in one of the following ways:


Selector syntax

• Selectors can be: – Literals – “color = ‘blue’”

– Byte strings - “myBytes = “0x0AFC23””

– Exact numeric literal - “NoItemsInStock > 20”

– Approximate numeric literal - “Difference < .7e+2”

– Boolean literals TRUE or FALSE - “AcctDetails = TRUE”

– Java identifiers – "JMSPriority >= 0"

– Whitespace - a space, form-feed, new-line, carriage return, horizontal

tab, or vertical tab

– Expressions - "Type = ’car’ AND color = ’blue’ AND weight > 2500"

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty - Decimal number, e.g. 21, -56, +45

- Hex number, e.g. 0xA, 0xAF, 0x2020. Hex numbers should begin with a zero,

followed by an upper/lowercase ‘x’. The remainder of the literal should contain n

valid hex characters where n > 1.

- Octal number, e.g. 0177, 0713. Octal numbers begin with a leading zero which is

followed by n digits in the range 0-7, where n >= 1. It should be noted that a leading

zero which is followed by one or more digits is always interpreted as being the start

of an octal number which means that it is not possible to represent a zero-prefixed

decimal number in this way, e.g. ‘09’ would return a syntax error as 9 is not a valid

octal digit.

Exact numeric literals may contain a trailing upper/lowercase ‘L’ character. This does not

affect how the number is stored or interpreted but is accepted as it is a valid addition to a

numeric literal.

• An approximate numeric literal is a numeric value in scientific notation, such as 7E3 and

-57.9E2, or a numeric value with a decimal, such as 7., -95.7, and +6.2; numbers in the

range -1.797693134862315E+308 to 1.797693134862315E+308 are supported. The

format of an approximate numeric literal is as follows:

The significand should follow an optional sign character (+ or -). The significand should be

either an integer or a fraction. The fractional part of the significand need not have a leading

digit.

An upper/lowercase E indicates the start of the optional exponent. The exponent has a

decimal radix and the number part of the exponent may be prefixed by an optional sign

character.

Approximate numeric literals may be terminated by upper/lowercase F or upper/lowercaseD. This syntax exists to support the cross-language method of tagging single or double

precision numbers. These characters are optional and do not affect how an approximate

numeric literal is stored or processed as these numbers are always stored and processed

using double-precision.

Terminating an exact numeric literal with a D or F does however cause that number to be

stored as an approximate numeric literal, e.g.

“3F + 4F = 7F” is equivalent to

“3.0 + 4.0 = 7.0”

• The Boolean literals TRUE and FALSE.

• An identifier is a variable-length character sequence that must begin with a valid

identifier start character, followed by zero or more valid identifier part characters. The

definition of a valid start/part character can be found in... /* For the docs, we need a

cross reference here to the text in 99961 which describes valid start/part characters */

- Identifiers cannot be the names NULL, TRUE , or FALSE .

- Identifiers cannot be NOT , AND , OR , BETWEEN , LIKE , IN , IS , or ESCAPE .

7/23/2019 WU6011-VU6011STUD


Student Notebook




- Identifiers are either header field references or property references. The type of a

property value in a message selector should correspond to the type used to set the

property, although numeric promotion will be performed if possible. If a type

mismatch occurs then the result of the expression is FALSE. If a property that does

not exist in a message is referenced, its value is NULL.

- Identifiers are case sensitive.

- JMS Message header field references:

JMS field and property names which map to property names or MQMD field names

may be used as valid identifiers in a selection string. WMQ will map the recognized

JMS field and property names to the message property values as defined in Chapter

13 of "Using Java". For instance, the selection string "JMSPriority >= 0" will select

on the Pri property found in the jms folder of the current message.

- JMS Message header field references in selectors are restricted to:

- JMSDeliveryMode

- JMSPriority

- JMSMessageID

- JMSTimestamp

- JMSCorrelationID

- JMSType

JMSMessageID, JMSTimestamp, JMSCorrelationID, and JMSType values can be null,

and if so, are treated as a NULL value.

- Any name beginning with JMSX is a JMS-defined property name and will bemapped to the appropriate MQMD field or property according to the rules used by

the WMQ JMS implementation.

- Any name beginning with JMS_ is a provider-specific property name. Recognized

property names of this form will be mapped to the appropriate MQMD field or

property according to the rules used by the WMQ JMS implementation.

- Any name that does not begin with JMS is an application-specific property name. If

there is a reference to a property that does not exist in a message, its value is NULL.

If it does exist, its value is the corresponding property value.

- Any JMS property names not matching the recognized set of header fields or

JMSX/JMS_ property names will be assumed to be user property names requiring

no mapping.

- When used in a message selector JMSDeliveryMode is treated as having the values

PERSISTENT and NON_PERSISTENT. This means, for example, that the

selection string “JMSDeliveryMode = ‘PERSISTENT’” is valid, whereas

“JMSDeliveryMode = 1” is not.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty • Expressions:

– A selector is a conditional expression; a selector that evaluates to true matches; a

selector that evaluates to false or unknown does not match.

– Arithmetic expressions are composed of themselves, arithmetic operations, identifiers

with numeric values, and numeric literals.

– Conditional expressions are composed of themselves, comparison operations, logical

operations, identifiers with boolean values, and Boolean literals.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-16. API Message selection with MQSUB WU6011.0

Notes:

A selector may be passed in on the call to MQSUB by using the SelectionString

MQCHARV field in the MQSD. The effect of passing in a selector on the MQSUB is that

only those messages published to the topic being subscribed to which match a supplied

selection string are made available on the destination queue.


Publisher

API Message selection with MQSUB

MQOPEN

ObjName = “MyDestQ”hObj

MyDestQ

MQSUBSelectionString = “sport = football”hObjTopicString = “Results”

MyDestQMQGETMQGET

team = hursley

sport = football

team = hursleysport = baseball

team = romsey

sport = football

Delivered!

Not Delivered!

Delivered!

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-17. API Message selection with MQOPEN WU6011.0

Notes:

A selector may be passed in on the call to MQOPEN by using the SelectionString

MQCHARV field in the MQOD. The effect of passing in a selector on the MQOPEN is that

only those messages on the opened queue which match a selector will be delivered to the

message consumer.

The main use for the selector on the MQOPEN verb is for the point-to-point case where an

application can elect to receive only those messages on a queue which match a selector.

The example above shows a simple scenario where two messages are put to an

MQOPENed queue but only one is received by the getting application as it is the only onewhich matches a selector.

Note that subsequent MQGET calls result in MQRC_NO_MSG_AVAILABLE as no further

messages exist on the queue that match the given selector.


Put Appl

API Message selection with MQOPEN

MQOPENObjName = “MyDestQ”

hObj MyDestQ

SelectorString = “team = hursley”

MQGEThObj

MyDestQ

team = hursley

sport = football

team = hursleysport = baseball

team = romsey

sport = football

Delivered!

Delivered!

Delivered!

MQRC_NO_MSG_AVAILABLE

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-18. Message token WU6011.0

Notes:


Message token

• Field in MQGMO version 3

• 16 byte identifier, unique within that queue

• Created by the queue manager when a message is placed on

a queue

• Does not follow the message from queue to queue

• Does not survive a queue manager restart

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-19. Message tokens in WMQ V7 WU6011.0

Notes:


Message tokens in WMQ V7

• Can be used as a match option for MQGET – MQMO_MATCH_MSG_TOKEN

– Previously available only on z/OS

• Can be used to improve message browsing – MQGMO_MARK_BROWSE_HANDLE marks a message token as

having been browsed by a single application

– MQGMO_MARK_BROWSE_CO_OP marks a message as having

been browsed by one of a co-operating set of applications

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-20. Simple browsing application WU6011.0

Notes:


Simple browsing application

• Each MQGET returns the message and marks it as browsed

• If you receive MQRC_NO_MSG_AVAILABLE, you have browsedthe entire queue – Even a priority queue with new messages

MQGET with

MQGMO_BROWSE_FIRST +

MQGMO_UNMARKED_BROWSE_MSG + MQGMO_MARK_BROWSE_HANDLE +

(MQGMO_WAIT optionally)

MQGET with

MQMO_MATCH_MSG_TOKEN

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-21. Cloned dispatchers WU6011.0

Notes:


Cloned dispatchers

• Multiple instances of co-operating programs – For example, Message Driven Beans in Java

• Dispatcher application browses the queue using

MQGET with


MQGMO_UNMARKED_BROWSE_MSG +

MQGMO_MARK_BROWSE_CO_OP +


Then dispatcher initializes a consumer and passes the

message token of selected message

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-22. Cloned dispatchers WU6011.0

Notes:


Cloned dispatchers

• Consumer program processes the selected message

• What if the message is not processed? – If consumer rolls back message, it is marked as not browsed

– If message is not processed within time interval MARKINT, it is

marked as not browsed

MQGET with


7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-23. Multiple dispatchers WU6011.0

Notes:


Multiple dispatchers

• Each dispatcher opens the queue with MQOO_CO_OP

• Dispatchers will be aware of others’ marked messages

MQGET with


MQGMO_UNMARKED_BROWSE_MSG +

MQGMO_MARK_BROWSE_HANDLE +


7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-24. Multiple dispatchers WU6011.0

Notes:


Multiple dispatchers

• If the message meets criteria,

• If not, then make the message available for another

dispatcher

MQGET with MQMO_MATCH_MSG_TOKEN

MQGET with


MQGMO_UNMARK_BROWSE_CO_OP

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-25. What is Asynchronous Consume ? WU6011.0

Notes:


What is Asynchronous Consume ?

• Function call driven by arrival of a message instead of MQGET

waiting for arrival of message

• No application thread tied up with waiting for a message

• Can provide asynchronous notification of events such as

connection termination or Queue Manager quiescing

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-26. What is an Asynchronous Consumer ? WU6011.0

Notes:


What is an Asynchronous Consumer ?

• An Asynchronous Consumer is a message-driven function orroutine, directly invoked by the queue manager to process the

messages.

• The message data is delivered in a ”Buffer”* so you normallydon’t need to do the MQGET by yourself, just process thepassed data.

• The advantage of this is: – Fewer critical resources spent doing nothing. – Don't need to allocate a buffer and 'guess' the message size

* For z/OS CICS, data is passed using ”channel containers”

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-27. An old MQI program WU6011.0

Notes:

Normally one program per queue.


pgma

An old MQI program

MQCONNMQCONN

MQOPEN(QUEUE1,&hObj1)MQOPEN(QUEUE1,&hObj1)

MQDISCMQDISC

pgma

MQGET(&hObj1)MQGET(&hObj1)

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-28. Message Driven ‘C’ single threaded application consuming from two queues WU6011.0

Notes:

This sample flow shows a single threaded application consuming messages from two

queues. The example shows all of the messages being delivered to a single inline function.

The difference from the asynchronous case is that control doesn’t return to the issuer of

MQCTL until all of the consumers have deactivated themselves, one consumer has issued

an MQCTL STOP request or the queue manager quiesces.

NOTE: If applications have particular requirements in terms of thread characteristics then

they can always create their thread accordingly then use MQCTL(MQOP_START_WAIT).

This has the effect of ‘donating’ the thread to MQ for async message delivery.


Message Driven ‘C’ single threaded application

consuming from two queues

MQCONNMQCONN


MQCB(hObj1, func1)MQCB(hObj1, func1)

MQCTL(MQOP_START_WAIT)MQCTL(MQOP_START_WAIT)

MQDISCMQDISC


MQCB(hObj2, func1)MQCB(hObj2, func1)

func1(....)func1(....)

Process messageProcess message

MQPUT1(md.ReplyQ,...)MQPUT1(md.ReplyQ,...)

returnreturn

pgma

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-29. Message Driven ‘C’ multithreaded application consuming from two queues WU6011.0

Notes:

This sample flow shows a multithreaded application consuming messages from two

queues. The example shows all of the messages being delivered to a single inline function.


Message Driven ‘C’ multithreaded application


MQCONNMQCONN


MQCB(hObj1,func2)MQCB(hObj1,func2)

MQCTL(MQOP_START)MQCTL(MQOP_START)

MQDISCMQDISC


MQCTL(MQOP_STOP)MQCTL(MQOP_STOP)

MQCB(hObj2,func2)MQCB(hObj2,func2)

func2(....)func2(....)

Pause, or do something elsePause, or do something else



returnreturn

pgma

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-30. Message Driven ‘C’ multithreaded application consuming from two queues WU6011.0

Notes:

This sample flow shows a multithreaded application consuming messages from two

queues. The example shows all of the messages being delivered to a single external

function.


pgmb

Message Driven ‘C’ multithreaded application


MQCONNMQCONN


MQCB(hObj1,”pgmb(func2)”)MQCB(hObj1,”pgmb(func2)”)

MQCTL(MQOP_START)MQCTL(MQOP_START)

MQDISCMQDISC


MQCTL(MQOP_STOP)MQCTL(MQOP_STOP)

MQCB(hObj2, ”pgmb(func2)”)MQCB(hObj2, ”pgmb(func2)”)

func2(....)func2(....)

Pause, or do something elsePause, or do something else



returnreturn

pgma

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-31. The called function can be: WU6011.0

Notes:

And IMS:

The MQ IMS bridge already provides message call back type functionality

z/OS: HFS/ZFS is NOT supported.


The called function can be:

• A function or an entry point in the program

• An external program – On Windows:

• A function in a dynamic-link library

– UNIX systems:• A function in a dynamically-loadable module or library

– z/OS:• Name of a load module (valid for LINK/LOAD macro)

– z/CICS• Name of a load module (valid for EXEC CICS LINK command)

– I5/OS• Library “/” Program or Library “/” ServiceProgram “(“ FunctionName “)”

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-32. New APIs to support Async Consume WU6011.0

Notes:

The MQCBC structure describes context information that is passed to a Call Back function.

The structure is an input/output parameter on the call to a message consumer routine

The MQCBD structure is used to specify a Call Back function and the options controlling its

use by the queue manager. The structure is an input parameter on the MQCB call

The MQCTLO structure is used to specify options relating to MQCTL. The structure is an

input / output parameter on the MQCTL call.


New APIs to support Async Consume

• MQCB – Manage callback functions – Message Consumer

• A message consumer callback function will be called when a message, meeting theselection criteria specified, is available on an object handle. – Event Handler

• The function will be called when an event, such as a queue manager or Connectionstopping or quiescing, occurs.

• MQCTL – Control callback functions

• New data areas – MQCBC – Call Back Context – MQCBD – Call Back Descriptor – MQCTLO – MQCTL options

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-33. MQCB – Register Message Consumer WU6011.0

Notes:


MQCB – Register Message Consumer

• Syntax – MQCB (Hconn, Operation, CallbackDesc, Hobj, MsgDesc,

GetMsgOpts, CompCode, Reason);• Operation

– MQOP_REGISTER Defines the call back function

– MQOP_DEREGISTER Stops the consuming of messages

– MQOP_SUSPEND Suspends the consuming of messages

– MQOP_RESUME Resumes the consuming of messages

• CallbackDesc – MQCBD New structure

• The other familiar parameters

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-34. MQCTL – Control Consumer WU6011.0

Notes:

Control callback function - Operation parameter

The operation being processed on the callback defined for the specified object handle. You

must specify one, and one only, of the following options:

MQOP_START

Start the consuming of messages for all defined message consumer functions for the

specified connection handle.Callbacks run on a thread started by the system, which is

different from any of the application threads.

This operation gives control of the provided connection handle to system. The only MQI

calls which can be issued by a thread other than the consumer thread are:

MQCTL with Operation MQOP_STOP

MQCTL with Operation MQOP_SUSPEND

MQDISC - This performs MQCTL with Operation MQOP_STOP before

disconnection the HConn.


MQCTL – Control Consumer

• Syntax – MQCTL (Hconn, Operation, ControlOpts, CompCode, Reason);

• Operation – MQOP_START - Start the consuming of messages for all defined Message

Consumer functions for the specified connection handle.

– MQOP_START_WAIT - Start the consuming of messages for all defined

Message Consumer functions for the specified connection handle.> This should imply that this option won't return until the connection is stopped,

suspended or there are no consumers

– MQOP_STOP - Stop the consuming of messages and wait for all Consumers

to complete before completing.

– MQOP_SUSPEND - Pause the consuming of messages.

– MQOP_RESUME - Resume the consuming of messages

• ControlOpts – MQCTLO_THREAD_AFFINITY - message consumers for the same

connection must use the same thread.

– MQCTLO_FAIL_IF_QUIESCING – use it...

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty MQRC_HCONN_ASYNC_ACTIVE is returned if a WebSphere® MQ API call is issued

while the connection handle is started, and the call does not originate from a message

consumer function.

If a connection fails, this has the effect of stopping the conversation as soon as

possible. It is possible, therefore, for a WebSphere MQ API call being issued on the

main thread to receive the return code MQRC_HCONN_ASYNC_ACTIVE for a while,

followed by the return code MQRC_CONNECTION_BROKEN when the connectionreverts to the stopped state.

This can be issued in a consumer function. For the same connection as the callback

routine, its only purpose is to cancel a previously issued MQOP_STOP operation.

This option is not supported in the following environments: CICS® on z/OS® or if the

application is bound with a nonthreaded WebSphere MQ library.

MQOP_START_WAIT

Start the consuming of messages for all defined message consumer functions for the

specified connection handle.Message consumers run on the same thread and control isnot returned to the caller of MQCTL until:

Released by the use of the MQCTL MQOP_STOP or MQOP_SUSPEND

operations, or

All consumer routines have been deregistered or suspended.

If all consumers are deregistered or suspended, an implicit MQOP_STOP operation is

issued.This option cannot be used from within a callback routine, either for the current

connection handle or any other connection handle. If the call is attempted it returns with

MQRC_ENVIRONMENT_ERROR.

If, at any time during an MQOP_START_WAIT operation there are no registered,

non-suspended consumers the call fails with a reason code of

MQRC_NO_CALLBACKS_ACTIVE.

If, during an MQOP_START_WAIT operation, the connection is suspended, the

MQCTL call returns a warning reason code of MQRC_CONNECTION_SUSPENDED;

at this point the connection remains ‘started’.

The application can choose to issue MQOP_STOP or MQOP_RESUME. In this

instance, the MQOP_RESUME operation blocks.

This option is not supported in a single threaded client.MQOP_STOP:

This operation releases the connection handle.

If issued from within a call back routine it does not take effect until the routine exits. No

more message consumer routines will be called after the consumer routines for

messages already read have completed and after stop calls (if requested) to call backs

have been made.

7/23/2019 WU6011-VU6011STUD


Student Notebook




If issued outside a call back control will not return to the caller until the consumer

routines for messages already read have completed and after stop calls (if requested)

to call backs have been made. The callbacks themselves will, however, remain

registered.

MQOP_SUSPEND:

Pause the consuming of messages. This operation releases the connection handle.

This does not have any effect on the reading ahead of messages for the application. If

you intend to stop consuming messages for a long period of time, consider closing the

queue and reopening it when consumption should continue.

If issued from within a callback routine, it does not take effect until the routine exits. No

more message consumer routines will be called after the current routine exits.

If issued outside a callback, control does not return to the caller until the current

consumer routine has completed and no more are called.

MQOP_RESUME

Resume the consuming of messages. This option is normally issued from the mainapplication thread, but it can also be used from within a callback routine to cancel an

earlier suspension request issued in the same routine.

If the MQOP_RESUME is used to resume an MQOP_START_WAIT then the operation

will block.

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-36. An example of a callback program WU6011.0

Notes:


An example of a callback program

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-37. An example of a callback program WU6011.0

Notes:


An example of a callback program

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-38. An example of the message consumer WU6011.0

Notes:


An example of the message consumer

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 6-39. An example of an external consumer WU6011.0

Notes:


An example of an external consumer

NOTE: This is a windows sample.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-40. Asynchronous Consume in a unit of work WU6011.0

Notes:


Asynchronous Consume in a unit of work

• MQCTL can be used in conjunction with Global Units of Workbut there are some limitations

– Queue-manager-coordinated units of work• MQBEGIN may be used on either the main application thread or within

the consumer thread but the transaction cannot span across threads.• If an MQCTL call with Operation MQOP_START is issued between an

MQBEGIN and MQCMIT call, then the MQCTL will fail with reason codeMQRC_ASYNC_UOW_CONFLICT.

– Externally-coordinated units of work• To use asynchronous consume in an externally coordinated thread the

application should use MQCTL with Operation MQOP_START_WAIT.This means that all messages are delivered on the main applicationthread and therefore have the correct thread.

• An attempt to issue MQCTL with Operation MQOP_START while theconnection is XA Opened will fail with reason codeMQRC_ASYNC_XA_CONFLICT.

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 6-42. Usage Notes WU6011.0

Notes:


Usage Notes

• Call back routines should check the responses from all services they

invoke. If they detect a condition that can’t be resolved they should call

MQCB with operation MQOP_DEREGISTER or MQOP_SUSPEND toprevent repeated calls to the callback routine.

• If an exception is thrown whilst in the call back routine it will be treated

the same as any other exception thrown from within user code. If the

MQ exception handler is invoked it will ignore the exception, since we

are not actually in MQ code at this instance, and the exception will be

passed to any application or system exception handler.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:





properties




tokens





properties




tokens


Unit summary

7/23/2019 WU6011-VU6011STUD


Student Notebook




7/23/2019 WU6011-VU6011STUD


Student Notebook



© Copyright IBM Corp. 2008 Unit 7. New Commands and MQ Explorer Changes 7-1

5.1

empty Unit 7. New Commands and MQ ExplorerChanges


This unit describes the changes made to the MQSC commands and to

MQ Explorer in WebSphere MQ Version 7.



• Use MQ Explorer and MQSC commands to administer a

Publish/Subscribe environment

• Understand the usability enhancements to Version 7 • Explain the additional connection information available



References


7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Use MQ Explorer and MQSC commands to administer aPublish/Subscribe environment

• Understand the usability enhancements to Version 7

• Explain the additional connection information available





Unit objectives

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 7-2. Publish/subscribe administration WU6011.0

Notes:


Publish/subscribe administration

• New queue manager properties

• Topic objects

• Subscription administration

• Queue alias properties

• Test publish and subscribe

• Browse message properties

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-3. New queue manager properties WU6011.0

Notes:

PARENT

The name of the queue manager to which this queue manager is connected

hierarchically as its child.

PSRTYCNT

When the queued pub/sub daemon fails to process a command message under

syncpoint (for example a publish message that cannot be delivered to a subscriber

because the subscriber queue is full and it is not possible to put the publication on the

dead letter queue), the unit of work is backed out and the command retried this number

of times before the broker attempts to process the command message according to its

report options instead.

The initial value for this parameter on a new queue manager is 5.

Range is 0 to 999,999,999.

PSNPMSG


New queue manager properties

• DISPLAY QMGR PUBSUB – Continuing the V6 options of DISPLAY QMGR SYSTEM, EVENT, CHINIT and

CLUSTER• PARENT(string ) – name of the parent queue manager in

publish/subscribe hierarchy

• PSRTYCNT(number/5 ) – The number of retries when processing (under

syncpoint) a failed command message (0-999999999)

• PSNPMSG(discard/keep) – Disposition of undelivered input message

• PSNPRES(normal/safe/discard/keep) – Controls the behavior of

undelivered response messages

• PSSYNCPT(ifper/yes) - Whether only persistent (or all) messages should

be processed under syncpoint

• PSMODE(enabled/disabled ) – Whether publish/subscribe engine is

running

• TREELIFE(number/1800 ) – Lifetime in seconds for non-administered

topics

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty If the queued pub/sub daemon cannot process a non-persistent input message it might

attempt to write the input message to the dead-letter queue (depending on the report

options of the input message). If the attempt to write the input message to the

dead-letter queue fails, and the MQRO_DISCARD_MSG report option was specified on

the input message or PSNPMSG=DISCARD, the broker discards the input message. If

PSNPMSG=KEEP is specified, the daemon will only discard the input message if the

MQRO_DISCARD_MSG report option was set in the input message. Note: IfPSSYNCPT=IFPER, PSNPMSG=KEEP must not be set.

DISCARD

Non-persistent input messages may be discarded if they cannot be processed.

KEEP

Non-persistent input messages will not be discarded if they cannot be processed. In

this situation the QPUBSUB will continue to retry to process this message at

appropriate intervals and does not continue processing subsequent messages.

PSNPRESIf the queued pub/sub daemon attempts to generate a response message in response

to a non-persistent input message, and the response message cannot be delivered to

the reply-to queue, this attribute indicates whether the daemon should try to write the

undeliverable message to the dead-letter queue or whether to discard the message. For

new queue managers, the initial value is NORMAL. If PSSYNCPT=IFPER, PSNPMSG

must not be set to KEEP or SAFE (i.e. it must be set to NORMAL or DISCARD).

For migrated queue managers on Windows, UIX and i5/OS, the value will depend on

DLQNonPersistentResponse and DiscardNonPersistentResponse as show by the

following grid:NORMAL

Non-persistent responses which cannot be placed on the reply queue are put on the

dead-letter queue. If they cannot be placed on the DLQ then they are discarded.

SAFE

Non-persistent responses which cannot be placed on the reply queue are put on the

dead-letter queue. If the response cannot be sent and cannot be placed on the

dead-letter queue then the QPUBSUB will back out of the current operation and

then retry at appropriate intervals and does not continue processing subsequent

messages.

DISCARD

Non-persistent responses which cannot be placed on the reply queue are discarded

KEEP

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty Note: Changing the PSMODE attribute might change the PSMODE status. Use

DISPLAY PUBSUB, or on iSeries DSPMQMPSST, to determine the current state of the

publish/subscribe engine and the queued publish/subscribe interface.

TREELIFE

The lifetime of non-administrative topics.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-4. New queue manager properties – MQ Explorer WU6011.0

Notes:


New queue manager properties – MQ Explorer

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-6. DEFINE TOPIC(topicname) WU6011.0

Notes:

(topic-name)

Name of the WebSphere MQ topic definition. The maximum length is 48 characters. This

is required.

The name must not be the same as any other topic definition currently defined on this

queue manager (unless REPLACE is specified).

TOPICSTR(string)

The topic string represented by this topic object definition. This parameter is requiredand cannot contain the empty string. The forward slash (/) character within this string

has special meaning. It delimits the elements in the topic tree. A topic string can start

with the "/" character but is not required to. A string starting with a "/" is not the same as

a string that starts without a "/" character.

The maximum length of the string is 10,240 characters.

CLUSTER


DEFINE TOPIC(topicname)

• TOPICSTR(topicstr ) – topic string

• CLUSTER(string ) – is this topic defined within a cluster?

• DEFPRTY( ) – default priority of messages published

• DEFPRESP(sync/async ) – default put response for fire and forget

• DEFPSIST(yes/no/asparent ) – default persistence

• DURSUB(yes/no/asparent ) – durable subscriptions allowed

• MDURMDL(string ) – model queue for durable subscriptions

• MNDURMDL(string ) – model queue for non-durable subscriptions

• PUB(enabled/disabled/asparent ) – publishing enabled

• SUB(enabled/disabled/asparent ) – subscribing enabled

• WILDCARD( passthru/block ) – behaviour of wildcard subscriptions

• PMSGDLV(asparent/all/alldur/allavail ) – delivery mechanism for persistentmessages

• NPMSGDLV(asparent/all/alldur/allavail ) – delivery mechanism for non-persistentmessages

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty The name of the cluster to which this topic belongs.

CMDSCOPE

This parameter applies to z/OS only and specifies how the command is executed when

the queue manager is a member of a queue-sharing group. CMDSCOPE must be

blank, or the local queue manager, if QSGDISP is set to GROUP.

DEFPRTY(integer)The default priority of messages published to the topic. The value must be in the range

zero (the lowest priority), through to the MAXPRTY queue manager parameter

(MAXPRTY is 9).

ASPARENT

The default priority is based on the setting of the closest parent administrative topic

object in the topic tree. This is the default supplied with WebSphere® MQ, but your

installation might have changed it.

DEFPSIST

Specifies the message persistence to be used when applications specify the

MQPER_PERSISTENCE_AS_TOPIC_DEF option.

ASPARENT

The default persistence is based on the setting of the closest parent administrative

topic object in the topic tree. This is the default supplied with WebSphere MQ, but

your installation might have changed it.

NO

Messages on this queue are lost during a restart of the queue manager.YES

Messages on this queue survive a restart of the queue manager. On z/OS, N and Y

are accepted as synonyms of NO and YES.

DEFPRESP

Specifies the put response to be used when applications specify the

MQPMO_RESPONSE_AS_DEF option.

ASPARENT

The default put response is based on the setting of the closest parent administrativetopic object in the topic tree. This is the default supplied with WebSphere MQ, but

your installation might have changed it.

SYNC

Put operations to the queue that specify MQPMO_RESPONSE_AS_Q_DEF are

issued as if MQPMO_SYNC_RESPONSE had been specified instead. Fields in the

MQMD and MQPMO are returned by the queue manager to the application.

7/23/2019 WU6011-VU6011STUD


Student Notebook




ASYNC

Put operations to the queue that specify MQPMO_RESPONSE_AS_Q_DEF are

always issued as if MQPMO_ASYNC_RESPONSE had been specified instead.

Some fields in the MQMD and MQPMO are not returned by the queue manager to

the application; but an improvement in performance might be seen for messages put

in a transaction and any non-persistent messages

DESCR(string)

Plain-text comment. It provides descriptive information about the object when an

operator issues the DISPLAY TOPIC command.

It should contain only displayable characters. The maximum length is 64 characters. In

a DBCS installation, it can contain DBCS characters (subject to a maximum length of 64

bytes).

Note: If characters are used that are not in the coded character set identifier (CCSID)

for this queue manager, they might be translated incorrectly if the information is sent to

another queue manager.DURSUB

Specifies whether applications are permitted to make durable subscriptions on this

topic.

ASPARENT

Whether durable subscriptions can be made on this topic is based on the setting of

the closest parent administrative topic object in the topic tree. This is the default

supplied with WebSphere MQ, but your installation might have changed it.

NODurable subscriptions cannot be made on this topic.

YES

Durable subscriptions can be made on this topic.

MDURMDL(string)

The name of the model queue to be used for durable subscriptions that request that the

queue manager manages the destination of its publications. The maximum length is 48

characters.

If MDURMDL is blank, it operates in the same way as ASPARENT values on otherattributes. The name of the model queue to be used will be based on the closest parent

administrative topic object in the topic tree with a value set for MDURMDL.

MNDURMDL(string)

The name of the model queue to be used for non-durable subscriptions that request

that the queue manager manages the destination of its publications. The maximum

length is 48 characters.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty If MNDURMDL is blank, it operates in the same way as ASPARENT values on other

attributes. The name of the model queue to be used will be based on the closest parent

administrative topic object in the topic tree with a value set for MNDURMDL.

NPMSGDLV

The delivery mechanism for persistent messages published to this topic:

ASPARENTThe delivery mechanism used is based on the setting of the first parent

administrative node found in the topic tree relating to this topic. This is the default


ALL

Non-persistent messages must be delivered to all subscribers, irrespective of

durability for the MQPUT call to report success. If a delivery failure to any subscriber

occurs, no other subscribers receive the message and the MQPUT call fails.

ALLAVAIL

Non-persistent messages are delivered to all subscribers that can accept the

message. Failure to deliver the message to any subscriber does not prevent other

subscribers from receiving the message.

ALLDUR

Non-persistent messages must be delivered to all durable subscribers. Failure to

deliver a non-persistent message to any non-durable subscribers does not return an

error to the MQPUT call. If a delivery failure to a durable subscriber occurs, no other

subscribers receive the message and the MQPUT calls fails.

PMSGDLV

The delivery mechanism for persistent messages published to this topic:

ASPARENT

The delivery mechanism used is based on the setting of the first parent

administrative node found in the topic tree relating to this topic. This is the default


ALL

Persistent messages must be delivered to all subscribers, irrespective of durability

for the MQPUT call to report success. If a delivery failure to any subscriber occurs,no other subscribers receive the message and the MQPUT call fails.

ALLAVAIL

Persistent messages are delivered to all subscribers that can accept the message.

Failure to deliver the message to any subscriber does not prevent other subscribers

from receiving the message.

ALLDUR

7/23/2019 WU6011-VU6011STUD


Student Notebook




Persistent messages must be delivered to all durable subscribers. Failure to deliver

a persistent message to any non-durable subscribers does not return an error to the

MQPUT call. If a delivery failure to a durable subscriber occurs, no other subscribers

receive the message and the MQPUT calls fails.

PROXYSUB

Controls whether a proxy subscription can be sent for this topic to directly connected

queue managers, even if no local subscriptions exist.

FIRSTUSE

A proxy subscription is sent for this topic only when a local subscription exists or a

proxy subscription is received that should be propagated to further

directly-connected queue managers.

FORCE

A proxy subscription is sent to connected queue managers even if no local

subscriptions exist. Note: The proxy subscription is sent when this value is set on

DEFINE or ALTER.

PUB

Controls whether messages can be published to this topic.

ASPARENT

Whether messages can be published to the topic is based on the setting of the

closest parent administrative topic object in the topic tree. This is the default


ENABLED

Messages can be published to the topic (by suitably authorized applications).

DISABLED

Messages cannot be published to the topic.

PUBSCOPE

Determines whether this queue manager propagates publications to queue managers

as part of a hierarchy or as part of a publish/subscribe cluster. Note: You can restrict

the behavior on a publication-by-publication basis, using MQPMO_SCOPE_QMGR on

the Put Message options.

ASPARENT

Whether this queue manager propagates publications to queue managers as part of

a hierarchy or as part of a publish/subscribe cluster is based on the setting of the

first parent administrative node found in the topic tree that relates to this topic.

QMGR

Publications for this topic are not propagated to connected queue managers.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty ALL

Publications for this topic are propagated to hierarchically connected queue

managers and to publish/subscribe cluster-connected queue managers.

SUB

Controls whether applications are to be permitted to subscribe to this topic.

ASPARENT

Whether applications can subscribe to the topic is based on the setting of the closest

parent administrative topic object in the topic tree. This is the default supplied with

WebSphere MQ, but your installation might have changed it.

ENABLED

Subscriptions can be made to the topic (by suitably authorized applications).

DISABLED

Applications cannot subscribe to the topic.

SUBSCOPE

Determines whether this queue manager subscribes to publications in this queue

manager or in the network of connected queue managers. If subscribing to all queue

managers, the queue manager will propagate subscriptions to them as part of a

hierarchy or as part of a publish/subscribe cluster. Note: You can restrict the behavior

on a subscription-by-subscription basis, using MQPMO_SCOPE_QMGR on the

Subscription Descriptor or SUBSCOPE(QMGR) on DEFINE SUB.

ASPARENT

Whether this queue manager will subscribe to publications in the same way as thesetting of the first parent administrative node found in the topic tree relating to this

topic.

QMGR

Only publications that are published on this queue manager will reach the

subscriber.

ALL

A publication made on this queue manager or on another queue manager will reach

the subscriber. Subscriptions for this topic are propagated to hierarchicallyconnected queue managers and to publish/subscribe cluster-connected queue

managers.

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty Displays the number of subscribers to this topic node, including durable subscribers

that are not currently connected.

SUBSCOPE

Determines whether this queue manager will propagate subscriptions, for this topic

node, to queue managers as part of a hierarchy or as part of a pub/sub operation. The

value can be QMGR or ALL.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-9. DISPLAY TPSTATUS(topicstr) TYPE(SUB) WU6011.0

Notes:

ACTCONN

Detects local publications, returning the currently active ConnectionId (CONNID) that

opened this subscription. This parameter is returned only when the value of ASSOC is

YES , indicating that. the subscription that is identified by the SUBID has an active

subscriber associated with it.

DURABLE

Indicates whether a durable subscription is not deleted when the creating application

closes its subscription handle, and persists over queue manager restart. The value can

be YES or NO .

LMSGDATE

The date on which an MQPUT call last sent a message to this subscription. The

MQPUT call updates the date field only when the call successfully puts a message to

the destination specified by this subscription. Note that an MQSUBRQ call causes an

update to this value.


DISPLAY TPSTATUS( topicstr ) TYPE(SUB)

• SUBID(string ) – unique subscription id, assigned by queue manager

• SUBUSER(string ) – userid that owns the subscription

• DURABLE(yes/no) – are durable subscriptions allowed for this topic?

• SUBTYPE(admin/api/proxy ) – how was this subscription created?

• ACTCONN(connid ) – currently active ConnectionId that has opened thissubscription

• RESMDATE(date) – date of most recent MQSUB

• RESMTIME(time) – time of most recent MQSUB

• LMSGDATE(date) – date of last MQPUT or MQSUBRQ to this subscription

• LMSGTIME(time) – time of last MQPUT or MQSUBRQ

• NUMMSGS(number ) – number of messages put to this destination

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 7-12. Topic status WU6011.0

Notes:


Topic status

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-13. Clear topic string WU6011.0

Notes:

(topic-string)

The topic string to be cleared. This string can represent several topics to be cleared by

using wildcards as shown in the table below.

Special CharacterBehavior

#Wildcard, multiple topic level

+Wildcard, single topic level

Note: the '+' and '#' are not treated as wildcards if they are mixed in with other

characters (including themselves) within a topic level. In the string below the '#' and '+'

characters are treated as ordinary characters.

level0/level1/#+/level3/level#

To illustrate this, the following example is used.

Clearing the following topic;


Clear topic string

• CLEAR TOPICSTR(topicstring ) CLRTYPE(RETAINED) – Removes the retained publication stored in the topic so that it is no

longer provided to subscribers

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




The level within the subscription hierarchy at which this subscription is made. The range

is zero through 9. The default value is 1.

SUBSCOPE

Determines whether this subscription should be forwarded to other brokers, so that the

subscriber receives messages published at those other brokers.

ALLThe subscription is forwarded to all queue managers directly connected through a

publish subscribe collective or hierarchy.

QMGR

The subscription forwards messages published on the topic only within this queue

manager.

USERDATA(string)

Specifies the user data associated with the subscription. The string is a variable length

value that can be retrieved by the application on an MQSUB API call and passed in amessage sent to this subscription as a message property.

VARUSER

Specifies whether a user other than the subscription creator can connect to and take

over ownership of the subscription.

ANY

Any user can connect to and takeover ownership of the subscription.

FIXED

Takeover by another USERID is not permitted.

WSCHEMA

The schema to be used when interpreting any wildcard characters in the topic string.

CHAR

Wildcard characters represent portions of strings.

TOPIC

Wildcard characters represent portions of the topic hierarchy. This is the default

value supplied with the product.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 7-16. Subscription administration – MQ Explorer WU6011.0

Notes:


Subscription administration – MQ Explorer

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-17. Display Sbstatus(genericname) WU6011.0

Notes:

DURABLE

Specify this attribute to restrict the type of subscriptions which are displayed.

ALL

Display all subscriptions.

NO

Only information about nondurable subscriptions is displayed.

YES

Only information about durable subscriptions is displayed.

SUBTYPE

Specify this attribute to restrict the type of subscriptions which are displayed.

USER

Displays only API and ADMIN subscriptions.


Display Sbstatus(genericname)

• DURABLE (yes/no)

• SUBTYPE ( proxy/admin/api) – how was this subscription created

• Status attributes:

– ACTCONN – returns the ConnId of the HConn that currently has this subscriptionopen

– LMSGDATE – date when a message was last published to this subscription

– LMSGTIME – time when a message was last published to this subscription

– NUMMSGS – number of messages put to this subscription

– RESMDATE – date of most recent MQSUB call connected to this subscription

– RESMTIME – time of most recent MQSUB call connected to this subscription

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 7-21. Test publish and subscribe – MQ Explorer WU6011.0

Notes:


Test publish and subscribe – MQ Explorer

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-22. Browsing message properties – MQ Explorer WU6011.0

Notes:

In order to see the Named Properties, at the top of the MQ Explorer window, choose

Window, then Preferences. In the left side of the window, left-click WebSphere MQ

Explorer, then Messages. On the right side of the window, click both Show message

properties and as Named Properties.


Browsing message properties – MQ Explorer

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 7-23. Usability enhancements for MQ Explorer WU6011.0

Notes:


Usability enhancements for MQ Explorer

• Welcome page

• New preferences

• Grouping of queue managers

• Import and export of settings

• New security options

7/23/2019 WU6011-VU6011STUD


7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 7-25. Preferences WU6011.0

Notes:


Preferences

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-26. Grouping of queue managers WU6011.0

Notes:


Grouping of queue managers

• MQ Explorer now supports the grouping of queue managers.

• Group of objects is called a Set.

• Actions may be performed on a set of queue managers: – Show/Hide All

– Connect/Disconnect All

– Start/Stop All Local

– Run Default/Custom Tests

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:



• Grouping can be done – Manually

– Automatically, by filtering on:• Command level

• Platform

• Any other queue manager attribute

• Queue managers may be members of none, one or many sets

• Sets may not contain other sets.

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:



7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:



7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-32. MQ Explorer Export / Import Settings WU6011.0

Notes:


MQ Explorer Export / Import Settings

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 7-33. MQ Explorer Export / Import WU6011.0

Notes:


MQ Explorer Export / Import

• When exporting – Be careful just to export what you

want – Do not export passwords....

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-34. Specify userid in MQ Explorer WU6011.0

Notes:


Specify userid in MQ Explorer

• We have enhanced the administration of remote queue

managers in MQ Explorer.

• We have reintroduced the easy way of administrating remote

connections in MQ Explorer again.

• We have added a userid and password dialogue.

• NOTE: You need an authorisation package like SupportPac MS0R to

authenticate your userids and passwords with the security infrastructure.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 7-35. Specify Userid for remote queue manager WU6011.0

Notes:


Specify Userid for remote queue manager

• You can specify userid and

password.

• Your password is kept safely on

your computer.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-36. Specify Userid for remote queue manager WU6011.0

Notes:


Specify Userid for remote queue manager

• You will be asked for a password

before connection.

– This happens if you didn’t store apassword.

– You will be asked for a “master”

password to open the password

storage on first connection.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 7-37. Controlling passwords dialogues WU6011.0

Notes:


Controlling passwords dialogues

• MQ Explorer can control if usersare allowed to save passwords

– Windows -> MQ Explorer ->Properties• Passwords

• You will be asked for an unlockpassword if you enter your ownkey. – Minimum 8 characters

• This is recommended to preventmisappropriation of your user

credentials.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-38. What is needed to secure the MQ Explorer WU6011.0

Notes:


What is needed to secure the MQ Explorer

• An authentication Security exit like PWServer in SupportPac

MS0R

• http://www-1.ibm.com/support/docview.wss?uid=swg24015658

• SupportPac MS0R supports currently: – Windows, Linux-32, Linux-64 (RH), z/Linux(),

– Solaris-X86, Solaris Sparc, iSeries, z/os

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 7-39. Additional object enhancements WU6011.0

Notes:


Additional object enhancements

• New server connection channel properties

• New queue properties

• New connection and status information

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-40. Changes to server connection channels WU6011.0

Notes:

MAXINST(integer)

The maximum number of simultaneous instances of an individual server-connection

channel that can be started. The value must be in the range zero through 999,999,999.

A value of zero prevents all client access on this channel.

If the value of this parameter is reduced to a number that is less than the number of

instances of the server-connection channel that are currently running, then those

running instances are not affected. However, new instances cannot start until sufficient

existing instances have ceased to run so that the number of currently running instancesis less than the value of this parameter.

This parameter is valid only for channels with a channel type (CHLTYPE) of

SVRCONN.

MAXINSTC(integer)


Changes to server connection channels

• DISPLAY CHANNEL(chlname) + CHLTYPE(SVRCONN) – Two new parameters

– MAXINST – maximum number of simultaneous instances of this

server connection channel by all clients• Zero to 999999999

– MAXINSTC – maximum number of simultaneous instances of this

server connection channel by a single client• Connections from a single network address

• Zero to 999999999

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty The maximum number of simultaneous individual server-connection channels that can

be started from a single client. In this context, connections that originate from the same

remote network address are regarded as coming from the same client. The value must

be in the range zero through 999,999,999. A value of zero prevents all client access on

this channel.

If the value of this parameter is reduced to a number that is less than the number of

instances of the server-connection channel that is currently running from individualclients, then those running instances are not affected. However, new instances from

those clients cannot start until sufficient instances have ceased to run that the number

of running instances is less than the value of this parameter.

This parameter is valid only for channels with a channel type (CHLTYPE) of

SVRCONN.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-41. SVRCONN channel properties – MQ Explorer WU6011.0

Notes:


SVRCONN channel properties – MQ Explorer

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 7-42. Read ahead queue property WU6011.0

Notes:

DEFREADA

Specifies the default read ahead behavior for non-persistent messages delivered to the

client. Enabling read ahead can improve the performance of client applications

consuming non-persistent messages.

NO

Non-persistent messages are not read ahead unless the client application is

configured to request read ahead.

YES

Non-persistent messages are sent to the client before an application requests them.

Non-persistent messages can be lost if the client ends abnormally or if the client

does not consume all the messages it is sent.

DISABLED


Read ahead queue property

• DEFINE QL / QM / QA (queuename) DEFREADA(yes / no / disabled )

– NO – Non-persistent messages are not read ahead unless the client defines it inthe MQOPEN – the default.

– YES – Non-persistent messages are sent to the client before the application

requests them.

– DISABLED – Messages are not sent ahead, regardless of the client application’s

request.

• MQ Explorer V7 remotely-administering queue managers can take

advantage of this. – More information in the Client Streaming presentation.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Read ahead of non-persistent messages in not enabled for this queue. Messages

are not sent ahead to the client regardless of whether read ahead is requested by

the client application.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 7-43. New queue properties – MQ Explorer WU6011.0

Notes:


New queue properties – MQ Explorer

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 7-44. New connection information WU6011.0

Notes:


New connection information

• The queue manager’s application connections – Will reflect handles that have opened topic objects to publish to those

objects

– Will reflect managed destination handles that have been returned from

MQSUB calls

– Will reflect subscription handles that have been returned from MQSUB

calls

• The queue manager’s application connections and queue

status information

– Will reflect the use of asynchronous consumers

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:










Unit summary

7/23/2019 WU6011-VU6011STUD


Student Notebook




7/23/2019 WU6011-VU6011STUD


Student Notebook



© Copyright IBM Corp. 2008 Unit 8. z/OS Enhancements 8-1

5.1

empty Unit 8. z/OS Enhancements


This unit describes the changes that have been made to WebSphere

MQ Version 7 for z/OS, including changes to security, security supportfor mixed case names, and the use of MQ Explorer for administration.



• Understand new MQ RACF classes.

• Identify new queue manager attribute.

• Identify changes to the REFRESH SECURITY command and new

parameters to be used with new MQ RACF classes.

• Understand the new mixed case profiles.

• Use MQ Explorer without Client Attachment Feature.

• Understand authentication using MQ Explorer.



References


7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Understand new MQ RACF classes.• Identify new queue manager attribute.

• Identify changes to the REFRESH SECURITY command and

new parameters to be used with new MQ RACF classes.











Unit objectives

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 8-2. New MQ RACF classes WU6011.0

Notes:


New MQ RACF classes

• MXADMIN

• MXQUEUE• MXPROC

• MXNLIST

• MXTOPIC

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 8-3. Queue manager attribute – security profile case WU6011.0

Notes:


Queue manager attribute – security profile case

• New queue manager parameter – SCYCASE

• UPPER – Only upper case security profiles are to be used by the queue manager. This

is the queue manager’s initial default setting.

• MIXED – Mixed case security profiles can be used by the queue manager. Changes to

this parameter are only effective after a successful REFRESH SECURITY(*)

TYPE(CLASSES) command is completed or after the queue manager has

been recycled. This parameter is only valid on z/OS.

• Display qmgr

– Display qmgr will allow you to display the new attribute SCYCASE of the queuemanager system. This parameter is only valid on z/OS.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 8-4. Changes to REFRESH SECURITY WU6011.0

Notes:


Changes to REFRESH SECURITY

• REFRESH SECURITY is used to refresh the new MQ RACF

classes. It can also be used in the Script (MQSC) Command.

• REFRESH SECURITY – MXADMIN

– MXQUEUE

– MXPROC

– MXNLIST

– MXTOPIC

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 8-5. Understand mixed case profiles WU6011.0

Notes:

Before WebSphere MQ for z/OS V7, you were not able to directly protect mixed-case

named objects. The only way was to use generic profiles, and you were not always sure of

what was protected.


Understand mixed case profiles

• WebSphere MQ V7 allows the use of mixed case characters in

object names. You can protect these objects by defining: – Mixed case profiles in the appropriate mixed case RACF classes, or

– Generic profiles in the appropriate uppercase RACF classes.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 8-6. Upper case only profiles WU6011.0

Notes:


Upper case only profiles

• There are some profiles, or parts of profiles, that remain uppercase onlyas the values are provided by WebSphere MQ. These are:

– Switch profiles

– All high-level qualifiers (HLQ) including subsystem and Queue-Sharing Groupidentifiers

– Profiles for SYSTEM objects

– Profiles for Default objects

– The MQCMDS class, so all command profiles are uppercase only

– The MQCONN class, so all connection profiles are uppercase only

– RESLEVEL profiles

– The 'object' qualification in command resource profiles; for example,hlq.QUEUE.queuename. The resource name only is mixed case

– Dynamic queue profiles hlq.CSQOREXX.* , hlq.CSQUTIL.*, and CSQXCMD.*

– The 'CONTEXT' part of the hlq.CONTEXT.resourcename

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 8-7. Mixed case profiles WU6011.0

Notes:


Mixed case profiles

• For example, if you have a queue called PAYROLL.Dept1 on

Queue Manager MQ01 and you are using:

– Mixed case classes; you can define a profile in the WebSphere MQ

RACF class MXQUEUE• RDEFINE MXQUEUE MQ01.PAYROLL.Dept1

– Uppercase classes; you can define a profile in the WebSphere MQ

RACF class MQQUEUE• RDEFINE MQQUEUE MQ01.PAYROLL.*

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 8-8. Refreshing mixed case profiles WU6011.0

Notes:


Refreshing mixed case profiles

• Use REFRESH SECURITY to carry out a security refresh. – REFRESH SECURITY (MXQUEUE)

– In this case, all MXQUEUE profiles will be refreshed,and new MXQUEUE profiles included will be valid.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 8-9. MQ Explorer without CAF WU6011.0

Notes:


MQ Explorer without CAF

• In previous versions, the z/OS Client Attachment Feature wasrequired if you wanted to administer MQ using MQ Explorer.

• On MQ V7, z/OS users will be allowed to create five “free”client attachments for use with MQ Explorer.

• The attachments must use SYSTEM.ADMIN.SVRCONN.

• MQ Explorer can be used to remotely administer and monitorMQ objects as topics and other publish/subscribe facilities.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 8-10. Authentication using MQ Explorer WU6011.0

Notes:


Authentication using MQ Explorer

• Security enhancements for remote administration using MQ

Explorer will be covered in the presentation on Client Security.

This presentation has all steps to set up security on the client

side.

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:
















Unit summary

7/23/2019 WU6011-VU6011STUD


Student Notebook



© Copyright IBM Corp. 2008 Unit 9. Client Enhancements 9-1

5.1

empty Unit 9. Client Enhancements


This unit describes the new functions added for clients in WebSphere

MQ Version 7. These include conversation sharing -- the ability toallow multiple instance of a client to share a single server connection

channel, asynchronous put -- also known as fire and forget, and read

ahead -- the queue manager's new ability to send messages to a

requesting client before the MQGET. These last two functions,

asynchronous put and read ahead, operate on the assumption that

some messages need even less message assurance than traditional

non-persistent messages.



• Describe the concept of client multiplexing or conversation sharing.

• Understand the Asynchronous Put feature.

• Code an Asynchronous MQPUT call.

• Use the Read Ahead options on a queue definition.

• Understand the changes to client exit programs.



References


7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Describe the concept of client multiplexing or conversationsharing.











Unit objectives

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-2. Introduction WU6011.0

Notes:


Introduction

• In MQ V6, if a client process made multiple connections to thesame queue manager

– It used different sockets for each connection – The queue manager used a separate thread for each connection

• In MQ V7, we introduce client multiplexing or conversation sharing.

• Multiple conversations can flow down the same TCP/IP socket.

• Only one queue manager thread will be used for the socket.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-3. Benefits WU6011.0

Notes:


Benefits

• Ensure that parent connections and their sessions talk to the

same queue manager

• Reduced number of sockets required

• Reduced server threads and reduced resource usage on the

queue manager

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-4. MQ V6 multithreaded clients WU6011.0

Notes:


MQ V6 multithreaded clients

C

l i e n t C o d e

L o c a l Q M g r

Thread OneThread One

Thread TwoThread Two

Thread ThreeThread Three

Thread Four Thread Four

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-5. MQ V7 multithreaded, multiplexing clients WU6011.0

Notes:


MQ V7 multithreaded, multiplexing clients

C l i e n t C o d e

L o c a l Q M g r

Thread OneThread One

Thread TwoThread Two

Thread ThreeThread Three

Thread Four Thread Four

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-6. Shared Conversations WU6011.0

Notes:


Shared Conversations

• Channel setup flows and security exchanges (including SSL) occur

once per socket. – Lightweight start-up for subsequent conversations on the socket

• On the SVRCONN end of channel, conversations are handled by

one receive thread.

• Side benefits: – Heartbeats from both ends of a client channel at all times

– Administrator STOP CHANNEL MODE(QUIESCE) is communicated immediately

to the client (though not necessarily to the application program)

• TCP/IP only; CLNTCONN / SVRCONN only

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-7. Shared Conversations WU6011.0

Notes:


Shared Conversations

• No promise is made about the relative ordering of data sent

down different connections and/or sessions.

• The reduction in SVRCONN MCA resource usage by moving

away from one thread per conversation can be very significant.

• Cannot work for non-threaded clients. – The solution relies on multiple threads in the client.

• Synchronous and asynchronous flows can share the same

conversation.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-8. Shared conversation coding WU6011.0

Notes:


Shared conversation coding

• In general, use of multiplexing is transparent to the application.

• Client application has some control over conversation sharing

with MQCONNX MQCNO options

– MQCNO_NO_CONV_SHARING

• Only one connection per socket.

• Still supports V7 heartbeats and STOP(QUIESCE)

– MQCNO_ALL_CONVS_SHARE (default)

• All types of connection can share the socket

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-9. Shared conversation administration WU6011.0

Notes:

SHARECNV value overrides the application setting.

- These can be used to reset the functionality to how it was at V6 which could be

useful if it is essential to preserve the behaviour of an existing application or exit.

- SHARECNV is useful for workflow reasons if you want to restrict the number of

conversations all sharing the same receive thread


Shared conversation administration

• SVRCONN channel parameters – SHARECNV: maximum level of conversation sharing allowed:

overrides MQCNO.• SHARECNV(0): run as at V6• SHARECNV(1): only one conversation on the socket, but it supports V7

features• SHARECNV(nnn): nnn is the maximum conversations per socket• Default is SHARECNV(10)

– SHARECNV value overrides the application setting.

• DISPLAY CHSTATUS

– MAXSHCNV – maximum number of shared conversations (the defaultis 10)

– CURSHCNV – current number on shared conversations on thischannel

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-10. Asynchronous Put (“fire and forget”) WU6011.0

Notes:


Asynchronous Put (“fire and forget”)

• One of the strengths of WebSphere MQ is, and remains, its ability toassure once and once only message delivery.

• Such high qualities of service are not required for all messages in allapplications.

• Async response from PUT or “Fire and Forget” is a feature that allowsmessages to be streamed down a network link without waiting forindividual replies.

• The feature is relevant in a client rather than bindings connection wherea high quality of service is not required.

• In the right circumstances significant performance improvement shouldbe seen.

• It is enabled by a combination of API settings and queue / topicdefinitions.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-11. MQPUT in binding mode WU6011.0

Notes:


MQPUT in binding mode

L o c a l Q M g r

MQPUT(Hconn,Hobj,MD,PMO,BuffLen,Buffer,CC,RC )


• Each message passed to

the queue manager and

stored safely.

• A completion and

reason code is returned

after each message is

written.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-12. MQPUT in V6 client mode WU6011.0

Notes:


MQPUT in V6 client mode

C

l i e n t C o d e

L o c a l Q M g r



• Each message is

passed to the queue

manager over the

network and stored

safely.

• CC and RC arereturned after each

message is written.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-13. MQPUT in client mode with Async Put WU6011.0

Notes:


MQPUT in client mode with Async Put

C l i e n t C o d e

L o c a l Q M g r



MQSTAT(Hconn,STyp,MQSTS,CC,RC )

OK

OK

• Client code returns

CC and RC “OK” and

sends the message

down the network.

• MQSTAT call gets

the status

information.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-14. New Put Message Options WU6011.0

Notes:

The following options control the response returned to an MQPUT or MQPUT1 call . You

can only specify only one of these options. If neither MQPMO_ASYNC_RESPONSE nor

MQPMO_SYNC_RESPONSE are specified,

MQPMO_RESPONSE_AS_Q_DEF/MQPMO_RESPONSE_AS_TOPIC_DEF is assumed.

MQPMO_ASYNC_RESPONSE

The MQPMO_ASYNC_RESPONSE option requests that an MQPUT or MQPUT1

operation is completed without the application waiting for the queue manager to complete

the call. Using this option can improve messaging performance, particularly for applicationsusing client bindings. An application can periodically check using the MQSTAT verb

whether an error has occurred during any previous asynchronous calls if required.

With this option, only the following fields are guaranteed to be completed in the MQMD;

ApplIdentityData, PutApplType, PutApplName, & ApplOriginData.

Additionally, if either/both MQPMO_NEW_MSG_ID (explicitly via PMO option or implicitly

by specifying MQMI_NONE in the MsgId field of the MQMD structure) or


New Put Message Options

• New options in MQPMO

• MQPMO_SYNC_RESPONSE – Assures the current (v6) behavior

• MQPMO_ASYNC_RESPONSE – API call may return to caller before message is delivered to the queue

manager we are connected to. – Not all the MQMD fields normally updated will be completed.

• MQPMO_RESPONSE_AS_Q_DEF – The option to be used is that implied by the DEFPRESP setting on the

queue definition

– Default value – MQPMO_RESPONSE_AS_TOPIC_DEF is a synonym.

7/23/2019 WU6011-VU6011STUD


Student Notebook




MQPMO_NEW_CORREL_ID are specified as options, the MsgId and CorrelId are also

completed.

Only the fields specified above are completed with this choice of put response type, other

information that would normally be returned in the MQMD or MQPMO structure are left

undefined (undefined may not necessarily mean not completed).

When requesting asynchronous put response for MQPUT or MQPUT1, a CompCode and

Reason of MQCC_OK and MQRC_NONE does not necessarily mean that the message

was successfully put to a queue. When developing an MQI application that uses

asynchronous put response and require confirmation that messages have been put to a

queue you should check both CompCode & Reason codes from the put operations and

also use MQSTAT to query asynchronous error information.

Although the success or failure of each individual MQPUT/MQPUT1 call may not be

returned immediately, the first error that occurred under an asynchronous call can be

determined at a later juncture through a call to the MQSTAT MQI verb.

In the instance that a persistent message under syncpoint is failed to be delivered using

asynchronous put response, if a commit of the transaction is attempted, this will fail and will

instead be backed out with a completion code of MQCC_FAILED and a reason of

MQRC_BACKED_OUT. The application can make a call to MQSTAT to determine the

cause of a previous MQPUT or MQPUT1 failure.

MQPMO_SYNC_RESPONSE

Specifying this value for a put option in the MQPMO structure ensures that the MQPUT or

MQPUT1 operation is always issued synchronously. Provided the operation was

successful, all fields in the MQMD and MQPMO are completed. It is provided to ensure a

synchronous response irrespective of whether the default put response value defined on

the queue or topic object.

MQPMO_RESPONSE_AS_Q_DEF

Put the message and request a response based on the DEFPRESP value specified on the

queue when it was opened by the application. In the scenario where a client application is

connected to a back level queue manager this value exhibits the behavior as if

MQPMO_SYNC_RESPONSE has been specified.

If this option is specified for an MQPUT1 call, the DEFPRESP value from the queue

definition is not used. If the MQPUT1 call is using MQPMO_SYNCPOINT it will behave as

for MQPMO_ASYNC_RESPONSE, and if it is using MQPMO_NO_SYNCPOINT is will

behave as for MQPMO_SYNC_RESPONSE.

MQPMO_RESPONSE_AS_TOPIC_DEF

This is a synonym for MQPMO_RESPONSE_AS_Q_DEF which can be used by

application developers when dealing with topic objects.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-15. When “Fire and Forget” applies WU6011.0

Notes:

To qualify for fire & forget put delivery a message must meet a set of qualification criteria.

The qualification criteria is carried out in two stages based on firstly the MQPMO option

field and secondly the MQMD persistence field. In a non-distribution list scenario, an

application put request is eligible for asynchronous delivery if, firstly, one of the following

conditions is true;

- The application MQPMO option field specifies MQPMO_ASYNC_RESPONSE

OR

.

- Issuing MQPUT, the application MQPMO options field specifies

MQPMO_RESPONSE_AS_Q_DEF (or its synonym

MQPMO_RESPONSE_AS_TOPIC_DEF) and the objects DEFPRESP attribute is

set to an asynchronous value at time it was opened.

And finally, one or more of the following conditions must also be true;

- The message is a persistent message being put within a unit of work


When “Fire and Forget” applies

When the MQPMO_ASYNC_RESPONSE option is set inMQPMO or taken from Q_DEF by default.

and

– Message is non-persistentor

– Persistent message is put within a unit of work

and

– Application is client connected.

Then an “OK” return from MQPUT may not mean the message has beendelivered.

If the message is not eligible then “normal” put occurs.

7/23/2019 WU6011-VU6011STUD


Student Notebook




OR

- The messages MQMD persistence is set to MQPER_NOT_PERSISTENT

OR

Issuing MQPUT, the messages MQMD Persistence is set to MQPER_AS_Q_DEF (or its

synonym MQPER_AS_TOPIC_DEF) and the objects DEFPSIST attribute is set to

non-persistent at time the object was ?????

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-16. Sync Point WU6011.0

Notes:


Sync Point

• A successful commit for a unit of work means that all persistent

async puts have been carried out successfully

• A subsequent MQGET (in the same Unit of Work) for an

asynchronously put message will succeed as normal.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-17. The MQSTAT call WU6011.0

Notes:

MQSTAT ( Hconn, Type, Stat, CompCode, Reason )

• Parameters

Parameter nameHconn

MQ data typeMQHCONN

Input/output Input

DescriptionThis handle represents the connection to the queue manager. The value of

Hconn was returned by a previous MQCONN or MQCONNX call.

Parameter nameType

MQ data typeMQLONG

Input/output Input

DescriptionThis is the type of status information being requested. It can be set to the

following value:


The MQSTAT call

• The new MQSTAT API call returns status of any async puts

that have occurred since the MQCONN or the last MQSTAT.

MQSTAT (Hconn, STyp, MQSTS, CC, RC)

– Styp – indicates call type - MQSTAT_TYPE_ASYNC_ERROR

– MQSTS – Status Information Structure

– A number of errors can occur including MQRC_CONNECTION_BROKEN

MQRC_FUNCTION_NOT_SUPPORTED MQRC_OPTIONS_ERROR

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty MQSTAT_TYPE_ASYNC_ERROR

This returns information about previous asynchronous MQPUT and MQPUT1

operations in the MQSTS structure passed on the call. The MQSTS structure passed

on the call is completed with the first recorded asynchronous warning or error

information for that connection.

An exception to this behavior is that in the event that an error occurs with a completion

code of MQCC_WARNING (for example MQRC_REPORT_OPTIONS_ERROR), a

subsequent failure with a completion code of MQCC_FAILED (for example

MQRC_Q_FULL) will be returned within the MQSTS information instead.

If no errors have occurred since the connection was established or since the last call to

MQSTAT then within the MQSTS structure the value of MQCC_OK is returned in the

CompCode field and the value of MQRC_NONE is returned in the Reason field.

Counts of the number of asynchronous calls that have been processed under the

connection handle are always returned irrespective of whether warning/errorinformation is logged via three counter fields; PutSuccessCount, PutWarningCount &

PutFailureCount. These counters are incremented by the queue manager each time an

asynchronous operation is processed successfully, has a warning or in a failure case

respectively (note that for accounting purposes a put to a distribution list counts once

per destination queue rather than per distribution list). Additionally MQSTAT will return

details of the first error or warning rather than a completion code of MQCC_WARNING

and reason code of MQRC_MULTIPLE_REASONS. (Note that in the instance that one

or more of the counters is about to be incremented beyond the maximum positive value

AMQ_LONG_MAX then the increment is not made ).

A successful call to MQSTAT results in any previous error information or counts to bereset.

Parameter nameStat

MQ data typeMQSTS

Input/output Input (Because its versioned)/Output

DescriptionStatus information structure

Parameter nameCompCode

MQ data typeMQLONGInput/output Output

DescriptionCompletion Code from MQSTAT call

Parameter nameReason

MQ data typeMQLONG

Input/output Output

7/23/2019 WU6011-VU6011STUD


Student Notebook




DescriptionReason Code from MQSTAT call

MQRC_API_EXIT_ERROR – 2374 – API exit failed.

MQRC_API_EXIT_LOAD_ERROR – 2183 – Unable to load API exit.

MQRC_CALL_IN_PROGRESS – 2219 – MQI call entered before previous call complete.

MQRC_CONNECTION_BROKEN – 2009 – Connection to queue manager lost.

MQRC_CONNECTION_STOPPING – 2203 – Connection shutting down.

MQRC_STS_ERROR – 2424 – Error with MQSTS structure.

MQRC_STAT_TYPE_ERROR – 2430 - Error with MQSTAT type.

MQRC_HCONN_ERROR – 2018 – Connection handle not valid.

MQRC_Q_MGR_STOPPING – 2162 – Queue manager stopping.

MQRC_RESOURCE_PROBLEM – 2102 – Insufficient system resources available.

MQRC_STORAGE_NOT_AVAILABLE – 2071 – Insufficient storage available.

MQRC_UNEXPECTED_ERROR – 2195 – Unexpected error occurred.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-18. The MQSTS structure WU6011.0

Notes:


The MQSTS structure

• MQSTS – StrucId – structure identifier

– Version – structure version number – CompCode – completion code of first error – Reason – reason code of first error – PutSuccessCount – number of async put calls succeeded – PutWarningCount – number of async put calls had warnings – PutFailureCount – number of async put calls had failures – ObjectType – failing object type – ObjectName – failing object name – ObjectQMgrName – failing object queue manager name – ResolvedObjectName – resolved name of destination queue – ResolvedQMgrName – resolved name of destination queue manager

• Returns information about events since last MQSTAT call. CompCodeand Reason relate to first occurrence of an MQCC_FAILED event (orMQCC_WARNING) if none.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-19. Queue Definition Default Put Response WU6011.0

Notes:


Queue Definition Default Put Response

• Keyword DEFPRESP values SYNC or ASYNC

• For QLOCAL, QMODEL,QREMOTE,QALIAS,TOPIC

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-20. Read ahead (client streaming) WU6011.0

Notes:


Read ahead (client streaming)

• Read Ahead is a feature that allows messages being read from a queue

to be sent by a queue manager to a client in advance of the MQGET

being issued.

• The feature is relevant in a client rather than bindings connection where

high Quality of Service is not needed.

• In the right circumstances significant performance improvement should

be seen.

• It is enabled by a combination of API settings and queue / topic

definitions.

• The feature is available to JMS clients also.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-21. MQGET in binding mode WU6011.0

Notes:


MQGET in binding mode

L o c a l Q M g r

MQGET(Hconn,Hobj,MD,GMO,BuffLen,Buffer,Len,CC,RC )

• Each message is

requested from the

queue manager and

passed to the

application.


7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-22. MQGET in V6 client mode WU6011.0

Notes:


MQGET in V6 client mode

C

l i e n t C o d e

• Each message

request flows over

the network to the

queue manager.

The message is

then returned over

network and

passed to the

application.

L o c a l Q M g r



7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-23. MQGET in client mode with Read Ahead WU6011.0

Notes:


MQGET in client mode with Read Ahead

• Client code reads

multiple messages

from the queue

manager.

• Those messages are

stored in memory for

delivery to the

application.

C l i e n t C o d e

L o c a l Q M g r





7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-24. New MQOPEN Options WU6011.0

Notes:

Read ahead options: The following options control whether non-persistent messages are

sent to the client ahead of an application requesting them.

MQOO_READ_AHEAD_AS_Q_DEF

Non-persistent messages are sent to the client ahead of an application requesting them

based on the default read ahead attribute of the queue being opened. This is the default

value.

MQOO_NO_READ_AHEAD

Non-persistent messages are not sent to the client ahead of an application requesting

them.

MQOO_READ_AHEAD

Non-persistent messages are sent to the client ahead of an application requesting them.

The following notes apply to these options:


New MQOPEN Options

• New options in MQOO

– MQOO_NO_READ_AHEAD• Assures the current (v6) behavior

– MQOO_READ_AHEAD• Non-persistent messages may be sent to the client ahead of an application

requesting them.

• Read ahead does not always happen. For example: the queue may be

disabled for Read Ahead.

– MQOO_READ_AHEAD_AS_Q_DEF

• The option to be used is that implied by the default Read Ahead setting on thequeue definition.

• Default value

• The options are only valid for local, alias, and model queues.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Only one of these options can be specified.

If both MQOO_READ_AHEAD and MQOO_NO_READ_AHEAD are specified reason code

MQRC_OPTIONS_ERROR is returned.

These options are only valid for local, alias, and model queues. They are not valid for

remote queues, distribution lists or any other object types.

These options are only applicable when one of MQOO_BROWSE,

MQOO_INPUT_SHARED and MQOO_INPUT_EXCLUSIVE are also specified although it

is not an error to specify these options with MQOO_ INQUIRE or MQOO_SET.

Read ahead may not be enabled when requested. The MQGET options used on the first

MQGET call may prevent read ahead from being enabled. Also, read ahead is disabled

when the client is connecting to a queue manager where read ahead is not supported.

If the application is not running as a WebSphere MQ client, these options are ignored.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-25. New MQSUB Considerations WU6011.0

Notes:


New MQSUB Considerations

• The options described for MQOPEN also apply to MQSUB where a

managed handle is being created. – Though they are “spelled” MQSO_... In this case.

• The properties specified then apply to the managed queue created

to receive the messages for the subscription.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-26. New MQCLOSE Options WU6011.0

Notes:

Read ahead options: The following options control what happens to non-persistent

messages which have been sent to the client ahead of an application requesting them and

have not yet been consumed by the application. These messages are stored in the client

read ahead buffer waiting to be requested by the application and can either be discarded or

consumed from the queue before the MQCLOSE is completed. Specify only one of these

options.

MQCO_IMMEDIATE

The queue is closed immediately and any messages which have been sent to the clientahead of an application requesting them are discarded and are not available to be

consumed by any application. This is the default value.

MQCO_QUIESCE

A request to close the queue is made, but if any messages which have been sent to the

client ahead of an application requesting them, still reside in the client read ahead


New MQCLOSE Options

• It is possible that when closing a queue messages are still inthe Read Ahead buffer.

• New options in MQCO – MQCO_IMMEDIATE

• Any messages in the read ahead buffer are discarded.• Default value

– MQCO_QUIESCE• If messages exist in the read ahead buffer MQCLOSE call will return with a

warning of MQRC_READ_AHEAD_MSGS and the queue handle will remainvalid.

• No more messages will be added to the read ahead buffer, though theremaining messages may be read.

• Programmer response is to consume the messages until an MQCLOSE withMQCO_QUIESCE option is successful.

• The options are only valid for queues.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty buffer, the MQCLOSE call will return with a warning of MQRC_READ_AHEAD_MSGS

and the queue handle will remain valid.

The application can then continue to use the queue handle to retrieve messages until

no more are available, and then close the queue again. The application should not

provide a specific MessageId or CorrelId when retrieving the remaining messages. No

more messages will be sent to the client ahead of an application requesting them, that

is read ahead is now turned off.

Applications are advised to use MQCO_QUIESCE rather than trying to reach a point

where there are no more messages in the client read ahead buffer, since a message

could arrive between the last MQGET call and the following MQCLOSE which would be

discarded if MQCO_IMMEDIATE was used.

If an MQCLOSE with MQCO_QUIESCE is issued from within an asynchronous call

back function, the same behaviour of reading ahead messages applies. If the warning

MQRC_READ_AHEAD_MSGS is returned, then the call back function will be called at

least one more time. When the last remaining message that was read ahead has been

passed to the call back function the MQCBC ConsumerFlags field is set toMQCBCF_BUFF_EMPTY.

This option is valid only for queues.

If the option is used for an object other than a queue the call fails with reason code

MQRC_OPTION_NOT_VALID_FOR_TYPE.

- Return values

2458 (X’099A’) MQRC_READ_AHEAD_MSGS

Explanation: On an MQCLOSE call, the option MQCO_QUIESCE was used and there are

still messages stored in client read ahead buffer that were sent to the client ahead of anapplication requesting them and have not yet been consumed by the application.

Completion Code: MQCC_WARNING

Programmer Response: Continue to consume messages using the queue handle until

there are no more available and then re-issue the MQCLOSE; or choose to discard these

messages by issuing the MQCLOSE call with the MQCO_IMMEDIATE option instead.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-27. Configuring the client WU6011.0

Notes:

You can specify read ahead configuration options for the client in the client configuration

file.

MaximumSize

When read ahead is enabled the client receives messages ahead of an application

requesting them. The messages are stored in the read ahead buffer on the client. The

buffer size can be altered by setting the MaximumSize attribute of the MessageBuffer

stanza in the client configuration file:

Minimum value

1

Maximum value

999999

Default value

1


Configuring the client

• Three configuration options apply.

• MessageBuffer Parameters

– MaximumSize• Default – Client Determines

– UpdatePercentage• Default – Client Determines

– PurgeTime• Default – No Purging

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty Note: The following special values of MaximumSize exist:

-1

The client determines the appropriate value

0

Read ahead is disabled for the client

UpdatePercentage

The client periodically updates the server with how much data the client application has

consumed. The amount consumed is expressed as a percentage of the available buffer

size.

The percentage can be altered by setting the UpdatePercentage attribute of the

MessageBuffer stanza in the client configuration file:

Minimum value

1

Maximum value

100

Default value

-1

Note: The following special values of MaximumSize exist:

-1

The client determines the appropriate value

PurgeTime

If the client application is selecting messages based on MsgId or CorrelId it is possible that

the read ahead buffer could contain messages sent to the client with a previously

requested MsgId or CorrelId. These messages would then be stranded in the read ahead

buffer until an MQGET is issued with an appropriate MsgId or CorrelId.

You can purge messages from the read ahead buffer by setting a message purge interval.

Any messages that have remained in the read ahead buffer for longer than the purge

interval are automatically purged. These messages have already been removed from the

queue on the queue manager, so unless they are being browsed, they will be lost.

By default no message purge of the read ahead buffer takes place.

The purge interval can be altered by setting the PurgeTime attribute of the MessageBuffer

stanza in the client configuration file:

Minimum value

0

Maximum value

7/23/2019 WU6011-VU6011STUD


Student Notebook




999999

Default value

0

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-28. Complete change of Java Exits WU6011.0

Notes:


Complete change of Java Exits

• Client security exits in JAVA have been redesigned to allow the

usage of client exits written in C and JAVA. – And to pass more options to the exits.

• This leads to more enhancements in MQ Explorer.

• The new implementation allows the usage of old JAVA exits for

compatibility reasons. You don’t need to rewrite your exits.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-29. Using a Client exit written in C WU6011.0

Notes:


Using a Client exit written in C

• You specify the client exit name

like this: module(function)

• And the location where MQ

Explorer can locate the module

• And optionally add a parameter to

the exit

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-30. Using a Client exit written in Java WU6011.0

Notes:


Using a Client exit written in Java

• You specify the client exit name

of the like this: classname

– com.ibm.dk.ClientExitIBM

• And the jar-file containing the

classname

• And optionally add a parameter to

the exit

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-31. Using a Client exit WU6011.0

Notes:


Using a Client exit

• The behavior of the signon

procedure depends on your

security exit.

• For example, it could have a pop-

up like this: – Fill in username, password and

domain.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-32. Why would we like to control SVRCONN ? WU6011.0

Notes:


Why would we like to control SVRCONN ?

• Because we would like to manage the resources used.

• We would not like a single workstation to monopolize our

systems. – This could be caused by a program bug

– Or by a Denial of Service (DoS) program

– Or by a unplanned roll-out of MQ-client application

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 9-33. Control number of SVRCONN connections WU6011.0

Notes:


Control number of SVRCONN connections

• We can use the MQ Explorer or

MQSC to adjust the attribute to

the values we want.

• MAXINST() – Maximum instances

• MAXINSTC() – Maximum instances per client (the

same as IP address)

• Default value: 999999999

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 9-34. Number of clients WU6011.0

Notes:


Number of clients

• The number of allowed clients

was reached.

• More connect attempts will be

refused.

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:














Unit summary

7/23/2019 WU6011-VU6011STUD


Student Notebook



© Copyright IBM Corp. 2008 Unit 10. Co-existence and migration of MQ / Message Broker 10-1

5.1

empty Unit 10.Co-existence and migration of MQ /Message Broker Publish/Subscribe


This unit describes the publish/subscribe abilities of WebSphere MQ

Version 6 and WebSphere Message Broker Version 6, and discusses

the migration paths from those versions to WebSphere MQ Version 7.



• Understand MQ V7 Publish/Subscribe support

• Understand Publish/Subscribe coexistence support of MQ V6 withMQ V7

• Understand Publish/Subscribe migration from V6 to V7

• Perform Publish/Subscribe migration

• Understand limitations



References


7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Understand MQ V7 Publish/Subscribe support• Understand Publish/Subscribe coexistence support of MQ V6

with MQ V7






with MQ V7




Unit objectives

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 10-2. Overview of MQ V7 publish/subscribe WU6011.0

Notes:

• Run strmqbrk -> ““migrating the broker's persistent state” (command semantic and

syntax change will be explained later)


Overview of MQ V7 publish/subscribe

• Provides a fully integrated publish/subscribe engine as a part of thequeue manager on both distributed and z/OS platforms.

• Supports coexistence of the new V7 publish/subscribe engine and MQV6 publish/subscribe by using a “queued pub/sub interface” - a shortterm replacement of MQ V6 pub/sub.

• Supports MQ V6 pub/sub using a new queue manager attributePSMODE and related daemon processes.

• Provides mechanisms to migrate pub/sub topic streams andconfigurations from MQ V6 (and MQ V5.3 with fixpak 8) state to MQ V7

state.

• IBM encourages customers to migrate MQ V6 pub/sub objects andconfigurations to the new MQ V7 pub/sub engine for more functionality.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 10-3. PSMODE: New queue manager attribute WU6011.0

Notes:


PSMODE: New queue manager attribute

• Allows dynamic control of the MQ V7 pub/sub engine and the V6queued pub/sub interface

• Three settings: – ENABLED (default) – allows both MQ V7 pub/sub engine and the V6 queued

pub/sub interface – DISABLED – all pub/sub functionality disabled – COMPAT – new pub/sub engine enabled but queued interface disabled

• PSMODE initial settings – ENABLED for new queue managers – COMPAT for queue managers migrating from V6 to V7

• Platform applicable: All

• Why compatibility mode?1)To allow Message Broker to read from the queues2)Once all applications have converted to new APIs - to turn off the use of the

queued interface.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 10-4. Coexistence: compatibility window WU6011.0

Notes:

PSMODE: can be changed dynamically to enable administration in situation such as Topic

being corrupted


Coexistence: compatibility window

• MQ V7 supports both V6 and V7 publish/subscribe.

• Existing MQ V6 pub/sub applications will continue working as is.

• Co-existence support controlled by queue manager attribute, PSMODE.

V6 QMgr withPub/sub

V7 QMgr withPub/sub

(PSMODE=ENABLED)

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 10-5. Coexistence support (1 of 3) WU6011.0

Notes:


Coexistence support (1 of 3)

• MQ V6 publish/subscribe engine will be replaced with a daemon

process that will support existing MQ V6 or Message Broker (MB) V6

applications.

• The daemon process will service old style (MQ/MB V6) applications by

mapping their queued input into the new MQ V7 API.

• The daemon will be started like the MQ V6 broker, i.e. from issuing theMQ V6 control command strmqbrk or from the MQ V6 service

runmqbrk.

• RFH1, RFH2 and PCF header messages will be supported. – Subscribers will receive the appropriate headers for their subscription, e.g. a

subscription that used an RFH to subscribe, will receive RFH publishes, whatever

format the publisher used.

• MQ V6 and MB V6 style wildcards are both supported via subscription

options.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty


Notes:



• Response messages – As MQ V7 uses synchronous calls, any response messages that are required will

be built up by the daemon process from the CompCode and Reason of thevarious MQ calls and put to the appropriate queue as specified by the MQMD

ReplyToQ and ReplyToQMgr.

• Content-based filtering and transformation will be continue to be

managed by Message Broker.

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:



• Command migmbbrk to migrate Message Broker / Event Broker

publish/subscribe

• Supports Message Broker V6 Delete Publication, Publish and

Subscription

• Streams will be supported (MQ V7 does not support the concept) – MQ V6 StreamName and Topic parameters will be used together to produce an

MQ V7 topic object and topic string

• Supports Retained publications

• Supports Inter-broker relationships (hierarchy only)

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 10-8. MQ V6 publish/subscribe migration WU6011.0

Notes:


MQ V6 publish/subscribe migration

• During MQ V7 installation – Existing queue managers get a new attribute PSMODE, initially set to COMPAT.

– New publish/subscribe engine is enabled. – Queued publish/subscribe interface is disabled.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 10-9. Control commands used in migration WU6011.0

Notes:


Control commands used in migration

•strmqbrk – Changed from “start the broker” to “migrate the broker's persistent state” – During migration persistent state remains unchanged; allows re-creation – Syntax

• New option “-l LogFileName” to log the migration• New option “-f” to force existing objects replacement during migration• Existing option “-p” supports existing customer scripts• Cannot be used to change the parent after MQ V7

•runmqbrk – Migrates the broker's persistent state; identical to strmqbrk

•dltmqbrk – Deletes the MQ V6 broker state – Does not remove the stream queues

•migmbbrk – Migrates Message Broker V6 publish/subscribe to MQ V7

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 10-10. Migration procedures (1 of 2) WU6011.0

Notes:

runmqbrk service is set to start automatically then migration is attempted. If it completes

successfully, inhibit it to prevent a “migration already complete” message each time the

service is run.

Otherwise, run strmqbrk

During the migration, messages issued during migration are written to the screen and to

the queue manager error logs. More detailed logging are written to the separate migration

log

Migration failures must be corrected and then runmqbrk/strmqbrk re-started in order to

complete the Pub/Sub migration.

After successful Pub/Sub migration, the PSMODE will be changed from

PSMODE(COMPAT) to PSMODE(ENABLED).


Migration procedures (1 of 2)

• Issue one of the following commands – runmqbrk

• Migration attempted if service is set to start automatically.

• After successful migration, inhibit to prevent a “migration already complete” messageeach time the service is run.

– strmqbrk

• Monitor migration – Messages written to the screen – Messages posted to the queue manager error logs – Detailed logging written to the separate migration log

• If migration fails – Diagnose and correct errors – Re-start runmqbrk or strmqbrk

• NOTE: After successful migration, PSMODE is changed from COMPAT toENABLED

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 10-11. Migration procedures (2 of 2) WU6011.0

Notes:

Upon successful migration and PSMODE is ENABLED, use dltmqbrk to delete the WMQ

V6 broker and its associated state

This will free the system resources associated with the broker.

It is possible to run dltmqbrk before Pub/Sub migration has been completed. However, this

will mean that all information relating to the WMQ v6 pub/sub configuration will be lost and

migration will then not be possible.

This command will delete the PRIMARY.STATE.QUEUE and all of the

SYSTEM.BROKER.IQ.x.y queues.

The migration (strmqbrk) will not perform any migration if these queues have been deleted,

thus signifying that migration has already been completed however strmqbrk will still turn

the queued Pub/Sub interface on even if no migration step is performed.


Migration procedures (2 of 2)

• Issue dltmqbrk to delete the migrated publish/subscribe state – Use only after successful migration and PSMODE is ENABLED

– Caution: using dltmqbrk before publish/subscribe migration is successfulprohibits a retry.

– Issuing dltmqbrk deletes the primary state queue and all of the related system

broker IQ queues. – strmqbrk

• Will not perform migration if these queues have been deleted.

• Will still turn the queued publish/subscribe interface ENABLED, even though no

migration has been performed.

• If stopping the pub/sub interface is required, the PSMODE should be set

to COMPAT (i.e. by MQSC command.)

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 10-12. Enabling and disabling PSMODE WU6011.0

Notes:


Enabling and disabling PSMODE

• MQ V7 Publish/Subscribe engine: – Allows startup of the pub/sub engine independent of the queue manager

– Allows clean up of pub/sub queues while the queue manager is running – Allows fixing corrupted pub/sub queues even if the queue manager is be unable to start.

• MQ V6 Publish/Subscribe Interface: – Maintains compatibility with V6 pub/sub

– Allows the use of MB or EB pub/sub with MQ V7 queue manager

– Allows startup of the queued pub/sub interface independent of the queue manager

startup

– Allows cleanup of corrupted pub/sub queues while the queue manager is running

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 10-13. Migration recovery WU6011.0

Notes:


Migration recovery

• Pub/sub migration failures must be corrected and thenrunmqbrk/strmqbrk re-started in order to complete the

migration.

• Be sure to back up MQ V6 system before attempting to install MQ

V7. – No reverting once MQ V7 is installed.

– Restore back to the starting MQ images if needed.

– Work done in MQ V7 will be lost.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 10-14. Deprecated function WU6011.0

Notes:


Deprecated function

• MQ V6 Metatopics – These special topics are of the form “MQ/S/QMgrName…” or

“MQ/SA/QMgrName/…”, the daemon will pass these messages through so that apublisher could be written to support these – nothing will be provided with theproduct though.

• MQ V6 Streams – MQ V7 does not support the concept of streams, however the daemon or new

MQ V7 style applications, can map streams to topic objects, thus enabling old andnew style applications to continue to communicate with each other. The defaultstream, SYSTEM.BROKER.DEFAULT.STREAM, will be recognised and mappedto a default topic object.

• MQ V6 Register/Deregister Publisher command – These commands will do nothing, except if a response message is required, the

daemon will build up a successful response message and put to the appropriatequeue as specified by the MQMD ReplyToQ and ReplyToQMgr.

• MQ V6 Routing Exit – There is no plan for a Pub/Sub routing exit in MQ V7.

7/23/2019 WU6011-VU6011STUD


Student Notebook




Figure 10-15. MQ for z/OS WU6011.0

Notes:


MQ for z/OS

• JMS publish/subscribe is possible on z/OS with MQ V7. z/OS

did not previously had a native MQ pub/sub engine.

• In MQ V6, publish/subscribe is supported by – The Message Broker/Event Broker interface to MQ

– Performing publish/subscribe messaging over MQ without using JMS

has been difficult, with applications having to manage broker control

and subscription messages, and RFH parsing, which JMS does for

them.

7/23/2019 WU6011-VU6011STUD


Student Notebook




5.1

empty

Figure 10-16. In summary WU6011.0

Notes:


In summary

• Existing state can be migrated into the new MQ V7

publish/subscribe.

• New MQ V7 publish/subscribe applications will work with

existing applications as is.

• Nearly all the MQ V6 pub/sub functionality is available in MQ

V7, plus new functionality and performance gains.

7/23/2019 WU6011-VU6011STUD


Student Notebook





Notes:




with MQ V7






with MQ V7




Unit summary

7/23/2019 WU6011-VU6011STUD


5.1

ackpgBack page

WU6011-VU6011STUD

Documents