WM1011-VM1011INST

V5.4.0.3

cover

Front cover

Technical Introduction to IBM WebSphere MQ (Course code WM101 / VM101)

Instructor GuideERC 1.0

WebSphere Education

Instructor Guide

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:

Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

Microsoft and Windows are trademarks 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.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

Other product and service names might be trademarks of IBM or other companies.

AIX® CICS® DB2®Domino® Everyplace® IMS™iSeries® Lotus® Maximo®MVS™ OS/390® OS/400®RACF® VTAM® WebSphere®z/OS® zSeries®

November 2011 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 2011.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.

Instructor GuideV5.4.0.3

TOC
Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Instructor course overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

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

Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Unit 1. Introduction to WebSphere MQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2The enterprise IT environment of today . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4IBM WebSphere reference architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6Why are interfaces so expensive to build and maintain? . . . . . . . . . . . . . . . . . . . . 1-9Service-oriented architecture (SOA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11Program-to-program communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13Synchronous application design model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16Extended asynchronous application design model . . . . . . . . . . . . . . . . . . . . . . . . 1-18Time independence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20Three styles of communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22WebSphere MQ eliminates application networking concerns . . . . . . . . . . . . . . . . 1-25Local and remote queues concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27MQI calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30Message composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-33Parallel processing application design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35Triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37Client/server application model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-40WebSphere MQ client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-42Data integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-44Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-47Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-50Checkpoint questions (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-53Checkpoint answers (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-55Checkpoint questions (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-57Checkpoint answers (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-59

Unit 2. Programming with WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Programming with the MQI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4MQI actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6MQI call notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9MQCONN call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11MQCONNX call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14Remote queue manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17MQOPEN call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19

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

© Copyright IBM Corp. 2011 Contents iii

Instructor Guide

Queue definition and independence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-22Model queue definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-24MQPUT call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-26MQGET call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-29MQGET get message options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-31MQPUT1 call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-34MQINQ call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-36MQSET call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-39Additional MQI calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-41Connecting to a queue manager with Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-43Accessing queues with Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-45The Java MQMessage object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-48Putting messages on the queue with Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-50Getting messages from the queue with Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-52Introducing Java Message Service (JMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-55JMS concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-57JMS APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-59JMS components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-61Relationship to other Java APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-63WebSphere MQ APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-65Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-67Checkpoint questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-69Checkpoint answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-71

Unit 3. Messages: additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2Some fields in the message descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3Message persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6Retrieval in priority order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8Report field and report message type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10Expiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13Message groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-16Message segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19Distribution list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-21Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23Checkpoint questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-25Checkpoint answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27

Unit 4. Intercommunication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2The message channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4Types of channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7Starting a channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10Stopping a channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12Remote queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14Message concentration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17Message segregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-19Multiple hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-21


iv WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011


TOC
Channel exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23Application data conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26Channel attributes example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28Queue manager clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31Cluster workload management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33Shared queues Sysplex support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35MQI client channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-38Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-40Checkpoint questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42Checkpoint answers (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-45Checkpoint answers (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-47
Unit 5. System administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6Administrative tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8WebSphere MQ administrative interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10WebSphere MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15WebSphere MQ Explorer: Queue Manager view . . . . . . . . . . . . . . . . . . . . . . . . . 5-17WebSphere MQ Explorer: Queues view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19WebSphere MQ Explorer: Queue selected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21WebSphere MQ Explorer: Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23WebSphere MQ Explorer: Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25WebSphere MQ Explorer: Filter results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27Queue storage management on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29Queue sharing on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31Log and bootstrap data sets on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33Journaling and recovery (iSeries) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36Logging and recovery: UNIX and Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41Checkpoint questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43Checkpoint answers (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-45Checkpoint answers (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-47

Unit 6. Transactional support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2Unit of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4Resource manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6Transaction manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8MQGET within sync point control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11MQPUT within sync point control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13Coordinating local units of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15Internal coordination of global units of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17Database coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19WebSphere MQ for z/OS RRS support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24Checkpoint questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26


© Copyright IBM Corp. 2011 Contents v

Instructor Guide

Checkpoint answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-28

Unit 7. Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2IBM security architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4Security implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7Security in WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9Resource access security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-12Command security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-14Message context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-16User IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-18Passing context information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-20WebSphere MQ channel security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-22Secure Sockets Layer (SSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-24Management and audit tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-26Using user ID context and alternate user ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-28Using channel message exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-30Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-32Checkpoint questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-34Checkpoint answers (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-36Checkpoint answers (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-38

Unit 8. Linking, bridging, and the WebSphere MQ family . . . . . . . . . . . . . . . . . . . . .8-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2The IMS bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4The CICS DPL bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6The CICS 3270 bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8The link for SAP R/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10WebSphere MQ Everyplace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-12Publish/subscribe examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14WebSphere MQ publish/subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16WebSphere Business Integration Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-18WebSphere Message Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-21Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-24Checkpoint questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-26Checkpoint answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-28

Unit 9. Course summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2Course learning objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4Class evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6To learn more on this subject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12

Appendix X-. List of abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .X--1


vi WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011


TMK
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:

Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

Microsoft and Windows are trademarks 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.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

Other product and service names might be trademarks of IBM or other companies.

AIX® CICS® DB2®Domino® Everyplace® IMS™iSeries® Lotus® Maximo®MVS™ OS/390® OS/400®RACF® VTAM® WebSphere®z/OS® zSeries®


© Copyright IBM Corp. 2011 Trademarks vii

Instructor Guide


viii WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011


TMK
Instructor course overview
This 1-day instructor-led course is a technical overview of IBM WebSphere MQ. It provides a conceptual understanding of messaging and queuing as implemented by IBM WebSphere MQ.

IBM WebSphere MQ delivers reliable application integration for applications and web services, allowing users to fully leverage existing software and hardware investments. Through a series of lectures, students learn how IBM WebSphere MQ provides a messaging backbone for deploying an enterprise service bus (ESB) as the connectivity layer of a service-oriented architecture (SOA). The course also explains how IBM WebSphere MQ responsibilities can include the management of topic-based publish/subscription information.

There are no lab exercises in this course; students confirm their learning through checkpoint questions.

After completing this course, students should be able to:

• Compare IBM WebSphere MQ with other forms of program-to-program communication

• Identify the impact WebSphere MQ can have on application design

• Describe the basic components and structure of IBM WebSphere MQ

• Describe the function of each of the calls in the Message Queue Interface

• Describe the tasks that must be performed to manage a queue manager and its connections with:

- Other queue managers

- WebSphere MQ client applications

• Describe the transactional support within the IBM WebSphere MQ product

• Describe the features of IBM WebSphere MQ that contribute to system security

• Explain how IBM WebSphere MQ can be used as part of the communications infrastructure to:

- Connect application environments, such as the World Wide Web, enterprise transaction systems, and database systems

- Manage the dissemination of publisher information to appropriate subscribers


© Copyright IBM Corp. 2011 Instructor course overview ix

Instructor Guide

Course strategy

Teaching strategy

Each classroom session uses a combination of facilitated lecture, discussions to convey the material.

Introduce the material

Inform the students of the objectives of the unit and topic. Give them a brief scenario that will help them understand how the presented material will assist them in performing their jobs.

Facilitate the learning experience

Involve the students in the learning process. Ask them questions and present classroom scenarios in which students use the available resources to solve situations involving process, procedure, or content on the job.

Review the material

Review objectives at the conclusion of each unit to ensure that the students have a thorough understanding of the material.

Course evaluation

Evaluation measures the quality, effectiveness, and impact of the course. It enables students to answer the question, "Are the requirements and objectives of the course being met?"

For all classes, students will provide feedback on course quality by completing an end-of-course questionnaire.

Measurement plan

There are no formal tests administered in the class.

Course materials

• Student Notebook • Instructor Guide • PowerPoint visuals in PDF form to be displayed

Summary of changes

November 2011 edition — WM101/VM101, ERC 1.0

This course is an update from the previous version course WM100, which was written for V7.0.

• Course base content taken from WM100/VM100


x WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011


TMK
• Updated for WebSphere MQ V7.1 • Updated for current WebSphere Education course standards
April 2008 edition — WM100/VM100, ERC 1.0

This course is an update from the previous version course WM010, which was written for V6.

• Course base content taken from WM010/VM010 • Updated for WebSphere MQ V7 • Additional detail on the IBM WebSphere MQ publish/subscribe • Changed all OS/390 references to zSeries • Updated course for new IBM WebSphere MQ new publisher/subscribe API • Publication/subscription added to Unit 8


© Copyright IBM Corp. 2011 Instructor course overview xi

Instructor Guide


xii WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011


TMK
Course description
Technical Introduction to WebSphere MQ

Duration: 1 day

Purpose

This 1-day instructor-led course is a technical overview of IBM WebSphere MQ. It provides a conceptual understanding of messaging and queuing as implemented by IBM WebSphere MQ.

IBM WebSphere MQ delivers reliable application integration for applications and web services, allowing users to fully leverage existing software and hardware investments. Through a series of lectures, students learn how IBM WebSphere MQ provides a messaging backbone for deploying an enterprise service bus (ESB) as the connectivity layer of a service-oriented architecture (SOA). The course also explains how IBM WebSphere MQ responsibilities can include the management of topic-based publish/subscription information.

There are no lab exercises in this course; students confirm their learning through checkpoint questions.

Audience

This basic course is designed for system administrators, application developers, and technical sales and marketing professionals.

Prerequisites

Before taking this course, students should have experience working with software. Skills and experience in one or more of the following specific areas enable students to derive more benefit from the course:

• Communications and networking • System and network management • System design • Application development • Transaction processing • Database management • Client/server solutions • Platform knowledge (IBM and non-IBM) • Open systems


© Copyright IBM Corp. 2011 Course description xiii

Instructor Guide

Objectives

After completing this course, students should be able to:

• Compare IBM WebSphere MQ with other forms of program-to-program communication

• Identify the impact WebSphere MQ can have on application design

• Describe the basic components and structure of IBM WebSphere MQ

• Describe the function of each of the calls in the Message Queue Interface

• Describe the tasks that must be performed to manage a queue manager and its connections with:

- Other queue managers

- WebSphere MQ client applications

• Describe the transactional support within the IBM WebSphere MQ product

• Describe the features of IBM WebSphere MQ that contribute to system security

• Explain how IBM WebSphere MQ can be used as part of the communications infrastructure to:

- Connect application environments, such as the World Wide Web, enterprise transaction systems, and database systems

- Manage the dissemination of publisher information to appropriate subscribers


xiv WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011


TMK
Agenda
Day 1

(00:30) Course introduction(00:30) Unit 1 - Introduction to WebSphere MQ(00:30) Unit 2 - Programming with WebSphere MQ(00:30) Unit 3 - Messages: Additional information(00:30) Unit 4 - Intercommunication (00:30) Unit 5 - System administration(00:30) Unit 6 - Transactional support(00:30) Unit 7 - Security(00:30) Unit 8 - Linking, bridging, and the WebSphere MQ family(00:15) Unit 9 - Course summary


© Copyright IBM Corp. 2011 Agenda xv

Instructor Guide


xvi WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011


Uempty
Unit 1. Introduction to WebSphere MQ
Estimated time

00:30

What this unit is about

This unit provides an overview of IBM WebSphere MQ. It introduces the business requirements that led to the development of IBM WebSphere MQ, positions it against other forms of program-to-program communication, and discusses the function it provides for building business application solutions.

What you should be able to do

After completing this unit, you should be able to:

• Explain the positioning of messaging and queuing in the current business environment

• Provide a high-level view of WebSphere MQ functions

• Describe the breadth of coverage of WebSphere MQ products

How you will check your progress

Accountability:

• Checkpoint questions

References

www.ibm.com/software/integration/wmqIBM WebSphere MQ home page

www.ibm.com/software/integration/wmq/libraryIBM WebSphere MQ Library

www.ibm.com/software/integration/wmq/quicktourIBM WebSphere MQ Quick Tour


© Copyright IBM Corp. 2011 Unit 1. Introduction to WebSphere MQ 1-1

Instructor Guide

Figure 1-1. Unit objectives WM101 / VM1011.0

Notes:

The intent of this course is to provide an introductory technical overview of IBM WebSphere MQ. The topics covered help you gain a solid foundation so you can begin building WebSphere MQ skills.

The purpose of this unit is to identify and help you understand the types of business requirements solved by WebSphere MQ, and to introduce how WebSphere MQ meets those requirements.

© Copyright IBM Corporation 2011

Unit objectives

After completing this unit, you should be able to:• Explain the positioning of messaging and queuing in the current

business environment• Provide a high-level view of WebSphere MQ functions• Describe the breadth of coverage of WebSphere MQ products


1-2 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011


Uempty
Instructor notes:
Purpose — Highlight the unit objectives.

Details — This unit introduces WebSphere MQ.

• You look at some examples of the types of environments that can use WebSphere MQ for complete solutions.

• You compare WebSphere MQ V7.1 to other communication models.

• You list the major strengths of the WebSphere MQ asynchronous model.

• You see the Message Queue Interface (MQI).

• You examine the contents of an WebSphere MQ message, as well as how it is delivered to applications.

Additional information —

Transition statement — Look at a business view of integration: the current IT environment.



Instructor Guide

Figure 1-2. The enterprise IT environment of today WM101 / VM1011.0

Notes:

Perhaps the biggest challenge is that current IT environments are becoming increasingly diverse. As the focus on integration increases, it moves horizontally, and extends beyond the boundaries of the individual enterprise to include partners, suppliers, and customers. It is this diversity in IT environments that increases the complexity of the challenges that a company like yours must handle.

Middleware is the infrastructure software that simplifies the problem of horizontal integration. The infrastructure has to integrate people, data, and applications across and beyond the enterprise to provide benefits throughout the value chain. Infrastructure middleware provides the operational resilience that is essential for making the technology transitions that allow your business to react quickly to necessary business changes, and to adapt dynamically.


The enterprise IT environment of todayIT environments are increasingly heterogeneous and complex

The role of modern middleware is to integrate and simplify

Transactions

Legacy systems and applications

Networks

Databases

Intranets

Value chain extranets

Internet

Customers




Uempty
Instructor notes:
Purpose — Describe the role of middleware.

Details —


Transition statement — Look at a business view of integration: the IBM WebSphere reference architecture.



Instructor Guide

Figure 1-3. IBM WebSphere reference architecture WM101 / VM1011.0

Notes:

The WebSphere platform provides the software foundation for On Demand Business.

WebSphere MQ started as a transactional application server, and has grown with customer needs. It provides software products delivering a breadth of business integration. While it emphasizes the value of the entire platform, IBM also allows the customer to start simply, using just the functionality required at the time, and then to progressively add function as needed. The IBM middleware platform is implemented as a service-oriented architecture (SOA), which IBM calls the IBM WebSphere Integration Reference Architecture.


IBM WebSphere reference architectureBusiness services

WebSphere Business Monitor

Infrastructure services

Developmentservices

WebSphere Business

IntegrationModeler,

WebSphere IntegrationDeveloper

Managementservices

Interactionservices

WebSphere Portal Server

Processservices

WebSphereProcess Server

Informationservices

WebSphereInformationIntegrator

Partnerservices

WebSphere Partner Gateway

Businessapplication

servicesWebSphere

Application Server

AccessservicesWBI and

WebSphere Adapters, HATS

Connectivity services, ESBWebSphere MQ

WebSphere Enterprise Service Bus, WebSphere Message Broker

Service registry




Uempty
Instructor notes:
Purpose — Outline WebSphere Business Integration Reference Architecture. Indicate how the layers are complementary. Different solutions may use subsets of the architecture functions; but the most value, that is, what is required for e-business on demand, is obtained when all the function of the architecture is leveraged and used.

Details — Begin at the bottom of the chart and work your way up the stack. Integration solutions typically begin with the fundamental need to interconnect multiple applications. Integration solutions can include prepackaged applications, like SAP, PeopleSoft, or Siebel. Integration solutions often include applications that were built years ago with no requirement or design considerations for interconnecting and interacting with other applications or components in a distributed system. There are three basic layers within the architecture.

• Application connectivity provides integration middleware that allows information to flow between the applications in a way that abstracts the details of the information flow from the applications themselves. This layer provides:

- Connectivity management to attach applications to a transport, isolating the details of the connection from the internals of the application. Connectivity management is provided through adapters.

- Information delivery management to determine the appropriate destination for the information flow and ensure that it is in the form required by the destination. It centralizes the logic so that it is not repeated in each of the interconnected applications.

• Process integration provides integration middleware that manages the execution of functions across heterogeneous, connected applications in a way that abstracts the details of the flow of activity from the applications themselves. This layer provides functions that:

- Catch and handle application events that need to be propagated to other applications.

- Control the flow of actions required among the interconnected applications.

- Allow the interaction of people and applications.

- Provide control and state management required for long-running processes.

• Modeling and monitoring provide for the creation of runtime assets that implement a business process. Graphical tools are used view, collect, and analyze data from the runtime system to upgrade the processes, effectively providing the necessary tools for continuous process improvement. This layer provides the functions required for:

- Efficient implementation of business processes.

- Analyzing and assessing process efficiency and effectiveness.

- Continuous business improvements through process management and change.



Instructor Guide

When appropriate, these layers can be extended to users through the functions and capabilities of WebSphere Portal technologies. The users may be employees or may access the system from outside the enterprise; for example, they may be customers, partners, or suppliers.

Also, when it is necessary to integrate third-party systems, the layers can be extended again, using the capabilities of the WebSphere Business Connect technologies.


Transition statement —




Uempty

Figure 1-4. Why are interfaces so expensive to build and maintain? WM101 / VM1011.0

Notes:

Why are interfaces so expensive to build and maintain?

There are several reasons. Application interface logic is typically intertwined within application business logic to the nature of the applications themselves. The programming models do not enable the separation of interface logic from the applications themselves.

The more tightly integrated the interface, the more difficult the application is to change.

The more interfaces within a program, the more complex the application becomes. Over time, and with enough separate connections, the interface logic can, in fact, exceed the business logic. In such circumstances, reuse becomes difficult and impractical.

SOA is the methodology and architecture for solving this problem.


Why are interfaces so expensive to build and maintain?

• Application interface logic is intertwined with business logic• Tightly integrated interfaces are difficult to change• The more interfaces, the more complex the application — interface

logic may exceed business logic.• Reuse becomes difficult and impractical



Instructor Guide

Instructor notes:

Purpose — To show the problems with interfaces.

Details —


Transition statement — SOA helps to make interfaces simpler and easier to maintain.




Uempty

Figure 1-5. Service-oriented architecture (SOA) WM101 / VM1011.0

Notes:

SOA is not a new concept. It is the next step of a connectivity evolution, and indeed, much of the problem has already been solved with existing technologies that you may be using today.

The objective of SOA is to reduce the service down to the bare business logic.


Service-oriented architecture (SOA)

Message queuing

Abstractsconnectivitylogic from application

Traditionalmessagebrokering

Abstractsconnectivity and mediation logic from application

Message and

service brokering

Reducesapplication to core business functions(that is, a service)

Application Application

Connectivity,mediation, andadditional logic

Directconnectivity

Connectivity, mediation, and additional logic

buried in application

Application

Connectivity logic

SERVICES

Connectivity,mediation, and

additionallogic

Mediation andadditional logic

Additional logic

Connectivity andmediation logic

Degree of flexibility and reuse

Lines of

code



Instructor Guide

Instructor notes:

Purpose — To introduce SOA.

Details — The concept of message queuing is a powerful one that you may be using if you use IBM products like IBM WebSphere MQ. IBM WebSphere MQ decouples applications by abstracting connections through the use of queues. Instead of the application talking directly to another application, it talks to an intermediate queue that can then be directed to any application. Message queuing also eliminates the need for the application to deal with the intricacies of different platforms or the worry about whether the other application is busy or even online. It also takes care to ensure that message delivery is assured and not duplicated. All of this capability strips out interface code from your application. However, message queuing itself does nothing to help deliver information in the right format. Nor does it help you direct information to different targets based on the message content. You still have to build all of this interface logic directly into your application interfaces. To eliminate this second level of interface logic, you need a different type of intermediary — a traditional broker. Brokers enable you to remove the transformation and routing logic from the application interfaces. Brokers can also augment content and reroute based on message content. They can also translate between different protocols and programming models.


Transition statement — What is WebSphere MQ?




Uempty

Figure 1-6. Program-to-program communication WM101 / VM1011.0

Notes:

WebSphere MQ is a means of program-to-program communication.

The figure depicts the basic mechanism by which this communication takes place. Program A prepares a message and puts it on a queue. Program B then gets the message from a queue and processes it.

Both Program A and Program B use an application programming interface (API) to put messages on a queue and get messages from a queue. The WebSphere MQ API is called the message queue interface (MQI).

When Program A puts a message on the queue, Program B might not be running. The queue stores the message safely until Program B starts and is ready to get the message. Likewise, at the time when Program B gets the message from the queue, Program A might no longer be running. With WebSphere MQ, there is no requirement for two programs communicating with each other to be running at the same time.


Program-to-program communication

BA

QueueApplication Application



Instructor Guide

WebSphere MQ provides several functions that are mandatory for successful message transport:

• Assured delivery

• Once-only delivery

• Asynchronous delivery




Uempty
Instructor notes:
Purpose — To explain the way in which program-to-program communication works using IBM WebSphere MQ.

Details — The main point is to make sure that everyone is comfortable with the high-level idea of using messaging and queuing for program-to-program communication. It may help to have them think of the queue pictures as a logical queue. As you go, you are introduced to the physical objects that make up the logical queue. It is also suggested that you may consider the queue as a replacement for an intermediate file, making sure that you point out that queues have certain advantages, which are covered as you progress.

Be sure to explain the three mandatory messaging functions that WebSphere MQ provides, namely:

• Assured delivery: a message is always delivered successfully, if the proper options are used.

• One-time delivery: a message is always delivered exactly one time, with no duplication, if the proper options are used.

• Asynchronous delivery: a message is always delivered even if the sending and receiving applications are not online at the same time.


Transition statement — What happens if Program B needs to send a message to Program A — perhaps a reply?



Instructor Guide

Figure 1-7. Synchronous application design model WM101 / VM1011.0

Notes:

The figure shows how Program B can send a message to Program A using the same mechanism. The message might be a reply to a message it received from Program A. Typically, Program B uses a different queue to send messages to Program A. Using a separate queue is not strictly necessary, but doing so leads to a simpler application design and simpler programming logic.

If Program A sends a message to Program B and expects a reply, one option is for Program A to put a message on Queue 1. It then waits for the reply to appear on Queue 2. This communication model is called the synchronous model for two-way communication between programs.

Using the synchronous model, Program A and Program B would normally be running at the same time. However, if Program B fails, Program A might potentially have to wait a long time for a reply. How long Program A waits before continuing with other processing is a design issue.


Synchronous application design model

BAQueue 1

Queue 2




Uempty
Instructor notes:
Purpose — To explain the synchronous model for two-way communication between programs.

Details — Point out that in the synchronous model is the inherent dependency that Program A and Program B must be available at the same time.


Transition statement — Next, you look at the asynchronous model.



Instructor Guide

Figure 1-8. Extended asynchronous application design model WM101 / VM1011.0

Notes:

Using the extended asynchronous model, Program A puts messages on Queue 1 for Program B to process, but Program C, acting asynchronously to Program A, receives replies from Queue 2 and processes them. Typically, Program A and Program C would be part of the same application.

The asynchronous model is a natural model for IBM WebSphere MQ. Program A can continue to put messages on Queue 1 and is not blocked by having to wait for a reply to each message. It can continue to put messages on Queue 1 even if Program B fails. In that case, Queue 1 stores the messages safely until Program B is restarted.

In a variation of the asynchronous model, Program A could put a sequence of messages on Queue 1, optionally continue with other processing, and then return to get and process the replies from Queue 2.


Extended asynchronous application design model

B

A

C

Queue 1

Queue 2




Uempty
Instructor notes:
Purpose — To explain the asynchronous model for two-way communication between programs.

Details — Now point out that the dependency shown in the previous visual has been removed.


Transition statement — You saw that Program A can continue to put messages on Queue 1 even if Program B fails.



Instructor Guide

Figure 1-9. Time independence WM101 / VM1011.0

Notes:

This figure demonstrates that Program A puts messages on the queue and Program B gets them when it is ready. If Program B is busy or is not available, the messages are stored safely in the queue until it is ready to get them.

If Program A has completed its processing when B becomes ready, or if Program A has failed, it does not matter. Program B can still get the messages and process them. Indeed, there may be times when neither program is available, but any outstanding messages are still stored safely in the queue.

This property of WebSphere MQ, in which communicating applications do not have to be active at the same time, is known as time independence.


Time independence

BA

BA

BA

BA

Not available

Not available

Not available

Not available




Uempty
Instructor notes:
Purpose — To highlight the time-independence property of WebSphere MQ.

Details — A concept to get across here is that everything is conditional. There are no hard requirements for a program to be available to get messages at the same time; another program is sending them.


Transition statement — Now compare WebSphere MQ with the other styles of program-to-program communication.



Instructor Guide

Figure 1-10. Three styles of communication WM101 / VM1011.0

Notes:

Conversational or transaction-oriented communication is characterized by two or more programs executing simultaneously in a cooperative manner in order to perform a transaction. They communicate with each other through a designed interface. While one program is waiting for a reply from another program with which it is cooperating, it can continue with other processing. APPC, CPI-C, and the socket interface to TCP/IP are examples of this style of communication.

The call-and-return style is similar, but when one program calls another program, the first program is blocked and cannot perform any other processing until the second program returns control to it. Remote procedure call (RPC) is an example of this style of communication.


Three styles of communication

Conversational

A B

A

B

Messaging

Call-and-return

A

Call B

B

Returnto A




Uempty
In the messaging style, communicating programs can run independently of each other. A running program receives input in the form of messages and also outputs its results as messages. A message that is the output from one program becomes the input to another program, but there is no requirement that the latter must be running when the former outputs the message. Contrast this style with the conversational and call-and-return styles where all cooperating partners must be running at the same time. WebSphere MQ uses this messaging style.


Instructor Guide

Instructor notes:

Purpose — To clarify the differences between the two synchronous styles of program-to-program communication and the asynchronous style that can be used with IBM WebSphere MQ.

Details — Thoroughly explain the three styles to students.

Examples of the conversational style are APPC, CPI-C, and the socket interface to TCP/IP. Using CPI-C, for example, the complexities of the network are fairly well-hidden, but not totally. Some, at least, of the LU6.2 conversation is exposed to the application programmer. When a program sends some data to another program and expects a reply, it may carry on with other processing for a while. However, it eventually must issue a communication receive, which may cause it to wait in a blocked state until the reply arrives. The implication is that the partner program is present and running. It is similar to a telephone conversation; both ends must be there and the line must be working for anything useful to happen.

The call-and-return style is similar. However, in implementation, it requires a more substantial piece of code to be linked to each program. This stub, as it is called, transfers control and parameters across the network, normally over TCP/IP. Both the calling and the called program work in a synchronous manner, and both partners must be executing at the same time.

The messaging style is the one used by WebSphere MQ. A program communicates with another program simply by sending it a message, but there is no requirement for the two programs to be active at the same time.


Transition statement — Next, you look at the networking requirements of WebSphere MQ compared to the requirements of the conversational style of program-to-program communication.




Uempty

Figure 1-11. WebSphere MQ eliminates application networking concerns WM101 / VM1011.0

Notes:

The conversational style of program-to-program communication relies on a communications connection existing across a network for each pair of applications. In reality, a communications connection manifests itself as a TCP connection, an SNA LU6.2 (system network architecture logical unit) conversation, a NetBIOS session, and so on.

In WebSphere MQ, an application sends a message to another application by using the Message Queue Interface (MQI) functions provided by the queue manager to which it is connected. Therefore, the required communications connection is between a pair of message channel agents (MCAs), each connected to its respective queue manager, not between a pair of applications.

The Message Queue Interface shields applications and their developers from the complexities of the network. The message channel agents supplied with WebSphere MQ contain all the communications programming that is necessary.


WebSphere MQ eliminates application network concerns

ApplicationsApplications

Network

Networkinginterface

Applications

MQI

Queue manager

Applications

MQI

Queue manager

Networkinginterface

Networkinginterface

MCAMCA



Instructor Guide

Instructor notes:

Purpose — To compare the networking requirements of WebSphere MQ and the conversational style of program-to-program communication.

Details — The conversational style of program-to-program communication requires that a communications connection exist between each pair of communicating applications.

In WebSphere MQ, it is the MCAs that are responsible for moving messages from one queue manager to another, so it is only each pair of MCAs that requires a communications connection. In this way, one communications connection can support multiple applications connected to one queue manager, sending messages to multiple applications connected to another queue manager.

Additional information — Keep the discussion at this level for now. Intercommunication has a full unit later on.

Transition statement — So far, it may seem as if everything is happening on one system. Often this requirement is true, but WebSphere MQ is able to connect applications over a network.




Uempty

Figure 1-12. Local and remote queues concept WM101 / VM1011.0

Notes:

When an application opens a queue, the queue manager determines the ultimate destination queue owner. If the queue is owned by the queue manager to which the application is connected, it is a local queue. If the queue is owned by another queue manager, it is a remote queue.

When the application puts a message on a queue that is local, the queue manager places the message directly on that queue. However, if the queue is remote, the queue manager places the message on a special local queue called a transmission queue.

A message channel agent is a component of WebSphere MQ. It is the task of the MCA to get the message from the transmission queue and send it over the network to the MCA at the receiving end. The receiving MCA then puts the message on the destination queue. Once the message has been safely committed on the destination queue, it is removed from the transmission queue.


Local and remote queues concept

Program BProgram A Program C

QM2:Local

queue,transmitqueue

Q1: Local queue

Queue manager

QM1

Queue manager

QM2

Q2: Local queue

System 1 System 2

MQPUTQ2, QM2

MQPUT Q1 MQGET Q1 MQGET Q2MQI

Dead letter queue



Instructor Guide

If the receiving MCA cannot put the message on the destination queue, the message is placed in the dead letter queue associated with that queue manager, or it can also be discarded, depending on the options specified by the sending application in the message descriptor.




Uempty
Instructor notes:
Purpose — Explain how a message is delivered safely to a remote destination queue.

Details — Walk the students through what happens when Program A puts a message on local queue Q1. This process is easy because the queue manager to which Program A is connected owns Q1, and therefore knows where it is.

However, when Program A puts a message on remote queue Q2, the queue manager to which Program A is connected needs to know which queue manager owns Q2. It also needs to know where that queue manager is located in the network. This process is done in various ways, which you discuss later. Do not be tempted to discuss these ways now. Assuming the queue manager knows this information, the message can be forwarded to that queue manager and put on the destination queue.

However, the delivery of a message to a remote queue needs to be done reliably, and once only. The queue manager to which Program A is connected identifies a local queue called a transmission queue, and puts the message on that queue. It is the task of an MCA to get the message from the transmission queue and send it to a partner MCA at the other end of a communications connection. The receiving MCA then puts the message on the destination queue Q2.

Once the receiving MCA has put the message on the destination queue, the protocol used by the two MCAs ensures that the message is removed from the transmission queue. If there is a communications failure during transmission, the same protocol also ensures that the two ends resynchronize when the communications connection is restored. Any messages that have been safely received are removed from the transmission queue at the sending end, and any messages that were not safely received are sent again. This protocol is called the Message Channel Protocol (MCP) and is responsible for ensuring that a message is delivered to a remote queue once only.

If a message cannot be delivered, it would normally be put on the dead letter queue at the receiving end. However, the sending application may specify other options.


Transition statement — Next, you look at an overview of the Message Queue Interface.



Instructor Guide

Figure 1-13. MQI calls WM101 / VM1011.0

Notes:

The component of WebSphere MQ that owns and manages queues is called a queue manager.

A queue manager also provides the message queue interface (MQI) to enable an application to access its queues and the messages they contain. The MQI is a simple application programming interface that is consistent across all platforms supported by WebSphere MQ. The MQI effectively protects applications from having to know how a queue manager physically manages messages and queues.

An application must first connect to a queue manager before it can access any of its resources. To connect to a queue manager, it issues an MQCONN or MQCONNX call. When the application no longer needs to be connected to the queue manager, it issues an MQDISC call.

To access a queue, an application must first issue an MQOPEN call. When it no longer requires access to the queue, the application issues an MQCLOSE call.


MQI calls

• Major calls– MQCONN– MQCONNX– MQDISC– MQOPEN– MQCLOSE– MQPUT– MQPUT1– MQGET– MQSUB– MQSUBRQ

• Minor calls– MQBEGIN– MQCMIT– MQBACK– MQINQ– MQSET

Applications

MQI

Queue manager

Queue manager objectNamelist object

Process definition

object




Uempty
Once a queue is opened, an application uses an MQPUT call to put a message on the queue and an MQGET call to get a message from the queue. An MQPUT with a Topic String is also used to publish information which can be established for subscribers of the published information. The MQCLOSE call releases access to the queue. The MQPUT1 call enables an application to open a queue, put one message on the queue, and close the queue, all in a single call.
The MQPUT1, MQCMIT, and MQBACK calls enable an application to put and get messages as part of a unit of work.

A queue is an example of a WebSphere MQ object. However, there are other types of WebSphere MQ objects, such as a process definition, a namelist, and queue manager objects.

The following functionality was introduced in WebSphere MQ V7: using MQPUT with topics, or topic strings, enables the publication of information. WebSphere MQ enables the subscription to publication information via the MQSUB and MQSUBR, which is outlined in Unit 8, “Linking.”

Every WebSphere MQ object has a set of attributes that describe the object. Each attribute has a name and a value. The definition of a WebSphere MQ object specifies the values of its attributes. Every WebSphere MQ object also has a name, which is considered to be one of its attributes. An application can use an MQINQ call to inquire on the values of the attributes of an object. It can use an MQSET call to set the values of certain attributes of a queue.

WebSphere MQ has two additional application programming interfaces: the Java interface for use in Java applications, and the Java Message Service (JMS), which allow programmers to write event-based messaging applications.



Instructor Guide

Instructor notes:

Purpose — To introduce the concepts of a queue manager and a WebSphere MQ object, and to describe the MQI calls.

Details — As shown in the figure, there are 10 major calls and five more specialized ones.

It is not necessary to go into the details of the calls here, as they are covered in the following units. Simply emphasize that this simple set of calls provides all the functionality that an application program needs to interact with WebSphere MQ.

It is sufficient to consider the following types of IBM WebSphere MQ objects:

• Queue managers • Queues • Process definitions — the attributes of an application that must be known to a queue

manager in order for the application to be started without operator intervention (used in triggering)

• Namelist — a WebSphere MQ object that contains a list of other WebSphere MQ objects

There are other types of WebSphere MQ objects as well.

WebSphere MQ V7 introduced the ability to publish using MQPUT with topic information. Subscriptions can be retrieved using the MQSUB and MQSUBR commands. More information is provided in Unit 8, “Linking, bridging, and the WebSphere MQ family.”


Transition statement — Look at a message in detail.




Uempty

Figure 1-14. Message composition WM101 / VM1011.0

Notes:

A message is composed of two parts: the various headers used by WebSphere MQ, and the application data.

All WebSphere MQ messages always have a header called the WebSphere MQ message descriptor (MQMD). The message descriptor contains control information about the message that is used by both the queue manager and the receiving application. It contains a number of fields that you review later in the course.

The application data is meaningful only to the applications that send or receive the message. It is possible to have a message with only a header and no application data.

There is no restriction on the content of the application data, but there is a maximum allowable length of 100 MB for a physical message. However, later in the course you see that messages larger than that size can still be processed.


Message composition

• Set by application and queue manager• Header

– MQMD (message descriptor)• Application data

– Any sequence of bytes– Meaningful only to the sending and receiving applications– Not meaningful to the queue manager

Application dataHeader

Message = header + application data



Instructor Guide

Instructor notes:

Purpose — To describe the two parts of a message.

Details — The application data (sometimes referred to as the “payload”) in a message has no meaning to the queue manager, and is not checked or processed in any way. Under certain circumstances, however, it may be converted from one character representation to another, and from one numeric representation to another, if wanted. You look more closely at application data conversion later in the course.

The message descriptor is used by the queue manager and the receiving application for the purposes of security, reporting, determining the sequence in which messages are delivered to the receiving application, and so on.

Some of the fields in the message descriptor are set by the application that puts the message on a queue; others are set by the queue manager on behalf of the application. Both the message descriptor and the application data are returned to the application that gets the message from the queue.

Do not get too deep on the contents of the message descriptor or the use of the other headers here. You look at the message descriptor in detail in Unit 3.

Additional information — In general, the default maximum message length is 4 MB, although you can increase it to a maximum length of 100 MB. An application is not limited to sending a maximum of 100 MB at a time; larger messages can be sent by using segmentation, which is discussed in Unit 3.

Transition statement — Next, you look at some types of application models for which WebSphere MQ is well-suited.




Uempty

Figure 1-15. Parallel processing application design WM101 / VM1011.0

Notes:

Booking a vacation with a travel agent may require a number of tasks. In the scenario depicted in the figure, an agent needs to reserve a flight and a hotel room, and rent a car. All of these tasks must be performed before the overall business transaction can be considered complete.

Using WebSphere MQ, a request message can be put on each of three queues which serve the car rental application, the flight reservations application, and the hotel reservations application. Each application can perform its respective task in parallel with the other two, and then put a reply message on the reply-to queue. The agent's application can then get the three replies and produce a consolidated answer.

This model allows several requests to be sent by an application without the application having to wait for a reply to one request before sending the next. All the requests can then be processed in parallel. Designing the system in this way can improve the overall response time.


Parallel processing application design

Car

Flight

Hotel

MQPUT CAR.RENTAL

MQPUT FLIGHT

MQPUT HOTEL

MQGET reply-to queue

CAR.RENTAL

FLIGHT

HOTEL

MQPUT

MQPUT

MQPUT

Reply-to queue



Instructor Guide

Instructor notes:

Purpose — To explain how WebSphere MQ enables applications to be built in which units of processing can be done in parallel, or possibly even on different systems.

Details — A more complex application may involve sending a number of requests to different servers. For example, a travel agent might use an application to arrange a trip for a customer. The requirements of the customer might mean that the application needs to make a number of requests — to make an airline reservation, to book a hotel room, to run a credit check, and so on.

By using queues, these steps do not have to be performed serially. The requests can be put on different queues, and processed in parallel.

The application might then wait until it has received all the replies before preparing a consolidated response. Alternatively, the business logic may define a time limit to wait for the replies. In that case, the application may present some form of partial response with limited information after that time has elapsed.

As you have seen previously, the application design may involve having a separate process to receive and process the replies.


Transition statement — Next, you look at how an application can be started automatically by the arrival of a message on a queue.




Uempty

Figure 1-16. Triggering WM101 / VM1011.0

Notes:

In WebSphere MQ, it is possible to arrange for an application to be started automatically when a message is put on a queue and certain conditions are satisfied. This facility is known as triggering.

The figure depicts the sequence of actions involved in triggering.

1. Program A puts a message on an application queue that is enabled for triggering.

2. If the conditions for triggering are met, a trigger event occurs, and the queue manager examines the process definition object referenced by the application queue. The process definition object identifies the application to be started, namely Program B.

3. The queue manager creates a trigger message whose fields contain information copied from certain attributes of the process definition object and the application queue, including the name of the application queue. The queue manager puts the trigger message on an initiation queue.

4. A long-running program called a trigger monitor gets the trigger message from the initiation queue, and examines its contents.


Triggering

Process definition

object

MQPUT A.Q

Program A

Trigger types:• FIRST• DEPTH• EVERY

Applicationqueue(A.Q)

Initiationqueue(I.Q)

Triggermonitor

1

2

34

6

5

MQGET I.Q

MQGET A.Q

Program B

Queue manager



Instructor Guide

5. The trigger monitor starts Program B, passing it information from the trigger message as a parameter, including the name of the application queue.

6. Program B opens the application queue and gets messages from it.

Triggering can occur based on selected conditions:

• The first time a message arrives on a queue

• When the number of messages on the queue reaches a predefined number

• Every time a message arrives on a queue




Uempty
Instructor notes:
Purpose — To explain how triggering works.

Details — Cover triggering only at a high level.

A trigger event may occur in one of three ways:

• The first message that arrives on the application queue can be the trigger event. In this case, the application would get the first message from the queue and continue to get any more messages that arrive later. It would terminate only if the queue is empty and no message arrives within a predetermined time.

• When the application queue reaches a specified depth, for example, 10 messages. The design of the started application would normally be similar to that of the previous case.

• Every message that is put on the application queue. In this case, the started application would normally be designed to get and process just one message before terminating. This option is a difficult option to use, both from the point of view of administration and from the point of view of application design. Its use is not, therefore, generally recommended. One problem is that it can cause multiple instances of a program or transaction to be scheduled within a short time, thus putting a strain on system resources.

It is possible to specify that messages below a certain priority are ignored by the queue manager when determining whether a trigger event should occur.

A trigger monitor may start the application synchronously within its own unit of execution or asynchronously as a separate unit of execution. It is worth pointing out that trigger monitors are supplied with WebSphere MQ, but users can write their own trigger monitors for the different operating systems and environments.


Transition statement — Next, you look at how WebSphere MQ can be used to implement client/server applications.



Instructor Guide

Figure 1-17. Client/server application model WM101 / VM1011.0

Notes:

The server application (insurance quotations) can handle requests from multiple client applications. Each application client is identical, and requests information from the application server. The message descriptor in each of the incoming messages identifies the appropriate reply-to queue for each request, so that the application server knows where to route the reply message.


Client/server application model

Insurance agent

Insurance agent

Insurance agent

Applicationclients

• Queue = service• Message = request• Reply-to queue name in

message descriptor• Multiple instances of

server possible

Insurancequotations

Applicationserver

Insurancedata




Uempty
Instructor notes:
Purpose — To explain how a queue can be viewed as a service, and how multiple clients can request the same service.

Details — The previous example described how a single client application can put messages on one or more queues in order to request the services of the applications serving those queues.

In general, multiple applications may put messages on the same queue in order to request the same service. The application serving the queue gets each message in turn and responds to it.

The message descriptor of each request message plays an important role here. One of the fields in the message descriptor is the name of the reply-to queue which informs the server application where to put the reply message. In this way, each client application can receive its replies separately from the replies of the other client applications.

The message descriptor also has a field to hold an identifier for a message. Furthermore, the message descriptor of a reply message can contain the identifier of the request message to which it relates (the correlation ID). In this way, a client application can correlate a reply with a request it sent previously.

If required, multiple instances of the server application may serve the same queue for increased throughput.


Transition statement — If an application wants to issue MQI calls to a queue manager, the application and the queue manager can be running on different systems.



Instructor Guide

Figure 1-18. WebSphere MQ client WM101 / VM1011.0

Notes:

A WebSphere MQ client is a component of IBM WebSphere MQ that allows an application running on a system where no queue manager exists to issue MQI calls to a queue manager running on another system.

The client stub receives the input parameters of an MQI call from the application and sends them over a communications connection to the server connection. The server connection is on the same system as the queue manager. The server connection then issues the MQI call to the queue manager on behalf of the application. After the queue manager has completed the MQI call, the server connection sends the output parameters of the callback to the client stub, which then passes them to the application.

Most MQI calls and options are available to the client application. The application simply issues an MQCONN (or MQCONNX, where supported) call to connect to a queue manager. Special consideration of WebSphere MQ client and database units of work are discussed later.

Not surprisingly, a reliable communications connection is required.


WebSphere MQ client

WebSphere MQ application

Communicationsstack

Client stub

WebSphere queue manager

Communicationsstack

Server connection

Client system Server system

(no queue manager exists on this system)

Communicationlink




Uempty
Instructor notes:
Purpose — To introduce the concept of a WebSphere MQ client.

Details — The advantage of using a WebSphere MQ client is that it allows a WebSphere MQ application to execute on a system without needing a queue manager on that system.


Transition statement — Next, you look at how WebSphere MQ can be used to implement a business transaction involving updates to databases residing on different systems.



Instructor Guide

Figure 1-19. Data integrity WM101 / VM1011.0

Notes:

Some implementations of the conversational style of program-to-program communication support the implementation of a distributed unit of work using a two-phase commit protocol. However, this function is only necessary when there is an absolute business requirement to maintain two or more distributed databases synchronously. If no such requirement exists, using a single distributed unit of work can be resource-intensive and complex, particularly if many processes are involved. WebSphere MQ offers a simple solution involving multiple units of work acting asynchronously.

The WebSphere MQ solution is depicted in the lower half of the figure.

• The first application writes to a database, puts a message on queue A.Q, and then issues a sync point to commit the changes to the two resources. The message contains data that is to be used to update a second database on a separate system. As the queue is a remote queue, the message gets no further than the transmission queue within this unit of work. When the unit of work is committed, the message becomes available for retrieval by the sending MCA.


Unit of work 3

Unit of work 1

Data integrity

Unit of work

WriteSend

Sync point

ReceiveWrite

Sync point

database

database

Database

Database

Two phasecommit

Unit of work 2Write

PutSync point

A.Q(xmitq) B.Q

Get

WriteSync point

Asynchronous model

Synchronous model




Uempty
• In the second unit of work, the sending MCA gets the message from the transmission queue and sends it to the receiving MCA on the system containing the second database. The receiving MCA then puts the message on the destination queue. These actions are performed reliably because of the assured delivery property of WebSphere MQ. When this unit of work is committed, the message becomes available for retrieval by the second application.
• In the third unit of work, the second application gets the message from the destination queue and updates the database using the data contained in the message.

The transactional integrity of units of work 1 and 3, and the “once only” and assured delivery properties of WebSphere MQ used in unit of work 2 ensure the integrity of the complete business transaction.

If the business transaction is a more complex one, multiple units of work may be involved.

Note: Using the WebSphere MQ Client requires the use of an XA-compliant transaction manager.



Instructor Guide

Instructor notes:

Purpose — Show how a business transaction can be implemented as multiple asynchronous units of work using WebSphere MQ, and compare this implementation with the more traditional approach of using a single distributed unit of work.

Details — The conversational style of program-to-program communication normally uses a two-phase commit protocol to ensure that changes to databases are synchronized. However, a two-phase commit protocol involves the locking of resources across a network, which can be difficult to plan and can lead to performance problems in a large and complex network of databases. Ask the students to imagine the amount of locking required and the possible impact on performance.

Additional information — You may be asked what happens if the database update in unit of work 3 fails for any reason. The answer is that unit of work 3 would need to send a message back to the originating system requesting that the database update made in unit of work 1 is rolled back. This action is known as a compensating transaction.

Transition statement — Next, you consider the security features provided by WebSphere MQ.




Uempty

Figure 1-20. Security WM101 / VM1011.0

Notes:

Security is an important aspect of system management. You look at the security features of WebSphere MQ in more detail later, but here is a brief overview of some of the security features that WebSphere MQ provides:

• A queue manager can check whether a user is authorized to enter commands that are used to manage the queue manager.

• A queue manager can check whether a user or an application is authorized to access a WebSphere MQ resource, such as a queue, for a specified operation.

• An MCA can authenticate a partner MCA before allowing messages to flow.

• A message can be encrypted before it is sent by an MCA to its partner MCA. At the receiving end, the message can be decrypted.

• A message descriptor normally contains a user ID field and other information about the originator of the message, called the message context. The message context can be used to authenticate a message, and to check whether the sender of the message is


Remote queue manager

Security

|USERID| |

Message context

Local queue manager

• Queues• Administrative

commandsMCA

MCA

Authenticationencryption

Database

MQMD Application data



Instructor Guide

authorized to access a WebSphere MQ resource on the system on which the message is received.

The user ID might also be used by the application to check whether the sender of the message is authorized to access a non-WebSphere MQ resource, such as a database. Whether an action is possible, depends on the security features provided by the respective resource manager.




Uempty
Instructor notes:
Purpose — To introduce the security features of WebSphere MQ. WebSphere MQ provides a framework structure that allows you or vendors to customize the services provided by WebSphere MQ.

Details — Do not go into detail as to what information can be examined in a message for security processing. Security is the entire content of Unit 7.


Transition statement — Review what you have covered so far.



Instructor Guide

Figure 1-21. Unit summary WM101 / VM1011.0

Notes:

This unit has discussed the functions and value that WebSphere MQ provides, at an overview level. Five major benefits of WebSphere MQ were highlighted:

• There is a common application programming interface, the MQI, that is consistent across all the supported platforms.

• WebSphere MQ can transfer data with assured delivery; messages do not get lost, even in the event of a system failure. Equally important is the fact that there is no duplicate delivery.

• The communicating applications do not have to be active at the same time. For example, a sending application can still be putting messages on a queue even though the receiving application is not active.

• Message-driven processing is a style of application design. An application is divided into discrete functional modules that can communicate with each other with messages. In this way, the modules can execute on different systems, be scheduled at different times; or they can act in parallel.


Unit summary

Having completed this unit, you should be able to:• Explain the positioning of messaging and queuing in the current

business environment• Provide a high-level view of WebSphere MQ functions• Describe the breadth of coverage of WebSphere MQ products




Uempty
• Application development is made faster by shielding the developer from the complexities of the network.


Instructor Guide

Instructor notes:

Purpose — To summarize the introductory unit.

Details — In this topic, you have looked at the nature of WebSphere MQ and have started to investigate its capabilities and functions. You have compared WebSphere MQ with other styles of program-to-program communication and have seen some of the implications on application design.

WebSphere MQ provides a means for program-to-program communication using messages and queues. The communicating applications can be on the same system, or they can be distributed across a network of IBM and non-IBM systems.






Uempty

Figure 1-22. Checkpoint questions (1 of 2) WM101 / VM1011.0

Notes:

1. WebSphere MQ uses an interface for programs to access resources called:

a. The program-to-program APIb. The Message Queue Interfacec. The synchronous modeld. Triggering

2. True or False: WebSphere MQ only supports messaging and queuing in an asynchronous environment.

3. True or False: In WebSphere MQ triggering, the queue manager starts the triggered program.


Checkpoint questions (1 of 2)

1. WebSphere MQ uses an interface for programs to access resources called:a. The program-to-program API.b. The Message Queue Interface.c. The synchronous model.d. Triggering.





Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty

Figure 1-23. Checkpoint answers (1 of 2) WM101 / VM1011.0

Notes:

1. WebSphere MQ uses an interface for programs to access resources called:

a. The program-to-program API.b. The Message Queue Interface.c. The synchronous model.d. Triggering.

Answer: b.


Answer: False. WebSphere MQ also supports messaging and queuing in synchronous environment.


Answer: False. The trigger monitor starts the triggered application.


Checkpoint answers (1 of 2)

1. WebSphere MQ uses an interface for programs to access resources called:a. The program-to-program API.b. The Message Queue Interface.c. The synchronous model.d. Triggering.Answer: b.

2. True or False: WebSphere MQ only supports messaging and queuing in an asynchronous environment. Answer: False. WebSphere MQ also supports messaging and queuing in a

synchronous environment.

3. True or False: In WebSphere MQ triggering, the queue manager starts the triggered program.Answer: False. The trigger monitor starts the triggered application.



Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty

Figure 1-24. Checkpoint questions (2 of 2) WM101 / VM1011.0

Notes:

4. A message consists of:

a. Application data.b. A WebSphere MQ trailer.c. A security header.d. A message descriptor.e. All the above.

5. All WebSphere MQ messages have a header. It is the:

a. MQXQH (transmission header).b. MQDLK (dead letter header).c. MQMD (message descriptor).d. MQTH (trigger header).


Checkpoint questions (2 of 2)

4. A message consists of: a. Application data.b. A WebSphere MQ trailer.c. A security header.d. A message descriptor.e. All the above.

5. All WebSphere MQ messages have a header. It is the: a. MQXQH (transmission header).b. MQDLK (dead letter header).c. MQMD (message descriptor).d. MQTH (trigger header).



Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty


Notes:

4. A message consists of:

a. Application data.b. A WebSphere MQ trailer.c. A security header.d. A message descriptor.e. All the above.

Answer: a and d. It is possible for a message to contain only a message descriptor and no application data.

5. All WebSphere MQ messages have a header. It is the:

a. MQXQH (transmission header).b. MQDLK (dead letter header).c. MQMD (message descriptor).d. MQTH (trigger header).

Answer: c. The MQMD is always included a WebSphere MQ message.



4. A message consists of: a. Application data.b. A WebSphere MQ trailer.c. A security header.d. A message descriptor.e. All the above.

Answer: a and d, although it is possible for a message to contain only a message descriptor and no application data. Security information, known as the “message context,” is part of the message descriptor.

5. All WebSphere MQ messages have a header. It is the: a. MQXQH (transmission header).b. MQDLK (dead letter header).c. MQMD (message descriptor).d. MQTH (trigger header).

Answer: c. The MQMD (message descriptor) is always included a WebSphere MQ message.



Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty
Unit 2. Programming with WebSphere MQ
Estimated time

00:30


This unit describes the functions provided by the message queue interface and some of the more common details of its use.



• Explain several calls provided by the MQI

• Explain the use of several calls at a high level

• Describe the details of the MQI

• Describe the Java interface and Java Message Services (JMS) in WebSphere MQ



References



© Copyright IBM Corp. 2011 Unit 2. Programming with WebSphere MQ 2-1

Instructor Guide


Notes:

This unit introduces each of the MQI calls and provides a high-level understanding of their use. On completion, you should be able to list each of the calls and describe their functions. The unit also introduces the Java and Java Message Service application programming interfaces.


Unit objectives

After completing this unit, you should be able to:• Explain several calls provided by the MQI• Explain the use of several calls at a high level• Describe the details of the MQI• Describe the Java interface and Java Message Service (JMS) in

WebSphere MQ




Uempty
Instructor notes:
Purpose — To introduce the discussion of the MQI.

Details — You are not trying to teach the students how to design or code WebSphere MQ applications. However, they need to have an idea of how these things work, since the course is a technical introduction. Even if some of them are managers or marketing representatives, you need to let them see the internal aspects that drive WebSphere MQ.

Transition statement — Even if you never examine the low-level functions in detail, you need to spend some time understanding how the WebSphere MQ engine works.



Instructor Guide

Figure 2-2. Programming with the MQI WM101 / VM1011.0

Notes:

The design principles behind the MQI are reflected in the interface. It is a simple call interface with a limited number of calls and a rich set of options for each call. Sensible default and initial values ensure that it is easy and quick to get applications up and running.

The MQI uses a number of structures and constants. WebSphere MQ supplies “include” files and “copy” files containing the definitions of these structures and their fields, and also the definitions of meaningful symbolic names to represent the constants within program logic.


Programming with the MQI

• Simple call interface

• Limited number of calls

• Rich in function

• Sensible default and initial values

• Supplied “include” files and “copy” files for the definitions of structures and constants

• Call syntax and examples available in the WebSphere MQ Information Center




Uempty
Instructor notes:
Purpose — To explain some of the philosophy behind the MQI.

Details — If customers are going to buy WebSphere MQ, it needs the characteristics depicted in the figure.

Transition statement — What does an MQI call look like?



Instructor Guide

Figure 2-3. MQI actions WM101 / VM1011.0

Notes:

The MQI is a simple call interface. The most common calls are:

MQCONN Connects to a queue manager

MQOPEN Establishes access to a WebSphere MQ object

MQPUT Places a message on a queue or publishes to a new topic

MQGET Retrieves a message from a queue

MQCLOSE Releases access to a WebSphere MQ object

MQDISC Disconnects from a queue manager

Some less common calls are:

MQPUT1 Opens a queue manager, places a message on the queue, and closes the queue manager

MQINQ Queries the attributes of a WebSphere MQ object

MQSET Changes the attributes of a queue


MQI actions

MQCONN

MQOPEN

MQGET

MQPUT

MQCLOSE

MQDISC

Application Queue manager

Q2Q1




Uempty
MQCONNX Connects to a queue manager using the specified options
MQBEGIN Begins a unit of work coordinated by the queue manager

MQCMIT Commits all message PUT and GET operations since the last sync point

MQBACK Backs out all message PUT and GET operations since the last sync point

MQSUB Registers subscriptions to a previously published topic

MQSUBRQ Requests a retained publication



Instructor Guide

Instructor notes:

Purpose — Show all the available calls.

Details — There is no need to go into detail with the calls on this slide, as each one is about to be explained in detail.

Additional information — MQSUB and MQSUBRQ have been added with the IBM WebSphere MQ V7.

Transition statement — Take a high-level view of these calls.




Uempty

Figure 2-4. MQI call notation WM101 / VM1011.0

Notes:

The WebSphere MQ Application Programming Reference defines the MQI calls. The figure shows an example of the notation used in that publication and others.

MQPUT1 is an example of an MQI call. The items in parentheses following it, namely Hconn, ObjDesc, and so on, are referred to as its parameters.

Examples of an MQPUT1 call in both C and COBOL are also shown in the figure. Other languages supported by WebSphere MQ include C++, PL/I, RPG, Java, Visual Basic, and .NET.


MQI call notation

• WebSphere MQ application programming referenceMQPUT1 (Hconn, ObjDesc, MsgDesc, PutMsgOpts, BufferLength, Buffer, CompCode, Reason)

• C equivalent MQPUT1 (Hconn, &ObjDesc, &MsgDesc, &PutMsgOpts, BufferLength, Buffer, &CompCode, &Reason);

• COBOL equivalent CALL "MQPUT1" USING HCONN, OBJDESC, MSGDESC, PUTMSGOPTS, BUFFERLENGTH, BUFFER, COMPCODE, REASON.



Instructor Guide

Instructor notes:

Purpose — Show what an MQI call looks like.

Details — Mention that sample programs in supported languages are provided on the various platforms. The WebSphere MQ Application Programming Guide and WebSphere MQ Application Programming Reference describe the syntax and usage of the calls and provide examples of them, including how to code the calls in the various programming languages

Transition statement — Investigate each of the MQI calls more closely, starting with the MQCONN call.




Uempty

Figure 2-5. MQCONN call WM101 / VM1011.0

Notes:

Before issuing any other MQI calls, an application must first connect to a queue manager by issuing an MQCONN call. The queue manager to which an application connects is known as the local queue manager. In general, you connect to a specific queue manager or to a default queue manager. An application normally needs authority to connect to a queue manager.

The MQCONN call has one input parameter and three output parameters. They are:

Queue manager name (input) The name of the queue manager to which the application wants to connect.

Connection handle (output) The connection handle represents the connection to the queue manager and must be specified as a parameter on all subsequent MQI calls to that queue manager.

Completion code (output) Every MQI call returns a completion code to enable the application to determine whether the call completed successfully, completed partially, or failed.


MQCONN callApplication

.

.MQCONN

.

.

Queuemanager

Connection

• Connection handle• Completion code• Reason code

Queue manager name

Call syntax: MQCONN (QMgrName, Hconn, CompCode, Reason)



Instructor Guide

Reason code (output) Every MQI call returns a reason code to provide more information to the application when a call completes partially or fails.

The application uses the MQDISC call to disconnect from a queue manager. When the MQDISC call is completed, the connection handle ceases to be valid.

Call syntax: MQDISC (Hconn, CompCode, Reason)




Uempty
Instructor notes:
Purpose — Introduce the MQCONN and MQDISC calls and the concept of a local queue manager.

Details — Make the point that a local queue manager is defined simply as the queue manager to which an application is connected. This definition applies even when the application is a WebSphere MQ client application, in which case the local queue manager may well be running on a different system from the application.

Additional information — WebSphere MQ for z/OS batch, iSeries, Windows, UNIX, and Compaq NonStop Kernel can use the MQCONN MQI call to connect, and the MQDISC MQI call to disconnect, from the queue manager.

CICS Transaction Server for z/OS and CICS for MVS applications do not connect to a queue manager because the CICS system itself is connected. However, you may want to use the MQCONN and MQDISC anyway, so that you can port these applications to environments other than CICS.

The MQDISC on CICS Transaction Server for z/OS applications is optional unless MQCONNX was used.

On iSeries, when you sign off from the OS/400 system, an implicit MQDISC call is made.

On VSE/ESA, if your application does not issue an MQDISC explicitly, the housekeeping routine issues the MQDISC call.

Transition statement — On some platforms, an additional means of connecting is available — MQCONNX.



Instructor Guide

Figure 2-6. MQCONNX call WM101 / VM1011.0

Notes:

The MQCONNX call is another means of connecting to the queue manager that is available on some platforms. MQCONNX is similar to MQCONN, but it allows for a “connection options” parameter to be passed. These connections options control the binding options for the connection.

Those parameters of the MQCONNX call that have not been described previously are:

Connection options (input/output) The binding options to be used when opening the connection

When an application connects to a queue manager using the MQCONN call, the queue manager code that is run to service each subsequent MQI call runs as a separate unit of execution from the application. When an application connects to a queue manager using the MQCONNX call, it can specify different binding options. One option is for “fast path binding.” Fast path binding causes the queue manager code that runs each subsequent MQI call to run within the same unit of execution as the application. The advantage of such an arrangement is that fewer system resources are required to run the application. The disadvantage is that the integrity of the queue manager can be compromised, as there is


MQCONNX call Application

.

.MQCONNX

.

.

Queuemanager

Connection

• Connection handle• Completion code• Reason code

• Queue manager name

• Connection options

Call syntax: MQCONNX(QMgrName, ConnectOpts, Hconn, CompCode, Reason)




Uempty
no protection from the application overwriting the storage used by the queue manager. In order to use fast path binding, the application must be run as a trusted application.
The MQCONNX call can be used:

• By clients to connect to a specific server and override any settings that would otherwise be in effect for that connection.

• To create a shared (thread-independent) connection that can be used by all threads in a process.

• To serialize application calls to a queue manager.



Instructor Guide

Instructor notes:

Purpose — To introduce the MQCONNX call.

Details — MQCONNX is not supported on Compaq NonStop Kernel or VSE/ESA.

Shared (thread-independent) connections is not supported on z/OS.

Transition statement — What is the relationship between an application and a queue manager other than the one to which it is connected?




Uempty

Figure 2-7. Remote queue manager WM101 / VM1011.0

Notes:

The figure shows two systems. System A is running two queue managers. The application connects to one of the queue managers, which then becomes its local queue manager. Access to a queue owned by the local queue manager is direct and synchronous.

The other queue manager on System A is termed a remote queue manager even though it is on the same system as the queue manager to which the application is connected. Any message originating from the application that is destined for a queue owned by the remote queue manager is delivered asynchronously by message channel agents (MCAs).

System B is also running a remote queue manager. Likewise, messages destined for queues owned by this queue manager are delivered asynchronously by MCAs.

The application issues an MQCONN call to the local queue manager on System A. If the MQCONN succeeds, the application has direct access to the queues owned by that local queue manager and can put messages on them, or get messages from them, in a synchronous manner.



Localqueue

Remotequeue

……

MQCONN…

Remotequeue

Local queue manager



System A

System B

Application



Instructor Guide

Instructor notes:

Purpose — To introduce the concept of a remote queue manager.

Details — For the application to send messages to queues owned by the other queue manager on the same system, MCAs are involved in delivering the messages. Thus, the messages are carried through the communications subsystem such as TCP/IP, even though they may never leave the system. The delivery of these messages is performed asynchronously to the execution of the application. An application may put a message on a remote queue, but it cannot get a message from a remote queue.

Transition statement — After an application has connected to a queue manager, how does it access a queue?




Uempty

Figure 2-8. MQOPEN call WM101 / VM1011.0

Notes:

Before an application can put messages on a queue or get messages from a queue, it must first open the queue by issuing an MQOPEN call.

The figure shows a local queue being opened using either a local queue, an alias queue, or model queue object.

MQOPEN can be used to open other types of WebSphere MQ objects such as a process definition, a namelist, or the queue manager object. You see later in this unit why an application might need to open an object other than a queue.

Those parameters of the MQOPEN call that have not been described previously are:

• Object descriptor (input/output) A structure defined in the MQI that identifies the object being opened. It contains a number of fields that specify, among other things, the name of the object being opened and the type of object.

• Options (input) The application uses this parameter to specify which operations it performs on the


MQOPEN callApplication

.

.MQOPEN

.

.

Connection

Queuemanager

• Connection handle• Object descriptor• Options

• Object handle• Completion code• Reason code

Call syntax:MQOPEN(Hconn, ObjDesc, Options, Hobj, CompCode, Reason)

Access



Instructor Guide

object being opened, or to control the action of MQOPEN. Examples include opening a queue for putting messages on it, opening a queue for browsing messages only, and opening a queue to inquire on the values of some or all of its attributes. An application may specify more than one option by adding the values together or by combining them using the bitwise OR operation.

An application normally needs the authority to open an object for each of the requested operations. These authorities are checked at the time the object is opened.

The application uses the MQCLOSE call to relinquish access to a queue, or any other type of IBM WebSphere MQ object. After the call, the object handle ceases to be valid.

Call syntax: MQCLOSE (Hconn, Hobj, Options, CompCode, Reason)




Uempty
Instructor notes:
Purpose — To describe the MQOPEN and MQCLOSE calls.

Details — A queue manager uses the information provided on an MQOPEN call to determine, for example, whether the queue being opened is one that it owns or is one that is owned by another queue manager.

It is worth stressing that only a local queue (including dynamic queues) can store messages. A local definition of a remote queue is a local object whose attributes contain sufficient information for the queue manager to be able to send messages to the queue. It cannot store messages itself. The remote queue referenced by a local definition of a remote queue is defined as a local queue on the remote queue manager that owns it.

Support for queues over 2 GB in size is available. The specifics on the maximum size and how to enable large queue support vary across operating systems. On AIX, HP-UX, and Sun Solaris, you need to enable large queues to be used. This process must be performed before you create queues with large sizes.

Transition statement — Look at the various types of queues with which an application can work.



Instructor Guide

Figure 2-9. Queue definition and independence WM101 / VM1011.0

Notes:

There are four types of queue that an application can open:

• Local queues

• Remote queues (local definitions of remote queues; cannot be opened for input)

• Alias queues

• Model queues (used to create queues dynamically)

Except for model queues, the syntax of the MQOPEN call is the same, irrespective of the type of queue being opened. For output queues, the common syntax allows the application architect or administrator to move a queue from one queue manager to another without having to rewrite the program.

The queue manager is responsible for resolving the name of the object being opened.


Queue definition and independence

Local queue

Transmission queue

Alias queue definition

Remote queue definition

Queue manager places messages in transmission queue

Target queue on remote queue manager

WebSphere MQ channel moves

messages across network

……

MQOPEN…

Local queue managerApplication


or

or or




Uempty
Instructor notes:
Purpose — Introduce queue transparency.

Details — When a program issues an MQOPEN, it always considers the object that is being opened to be local. The queue manager resolves the name of the object being opened.

If the name of the queue being opened has been defined as a remote definition of a queue on another system, the queue manager must ensure that the message is put on the proper transmit queue. It must also ensure that it contains the necessary routing information to enable delivery on the remote side.

If the name of the queue being opened is an alias, the queue manager must resolve that name to a definition of either a local or remote queue definition, and properly deliver the message.

Ultimately, the application program does not know whether the queue that it is opening is a local queue, an alias queue, or a remote definition of a queue on another system. The discussion with respect to remote queues implies opening queues for output. MQGETs may not be issued to a remote queue.

Additional information — Notice that you have avoided mentioning model queues. Model queues work differently and are covered shortly.

In the figure, highlight the distinction between queues that have messages and queues that do not. Alias queues and local definitions of remote queues are in effect merely elaborate pointers.

Transition statement — A closer look at a model queue and its use might help.



Instructor Guide

Figure 2-10. Model queue definition WM101 / VM1011.0

Notes:

A model queue is a template that is used to define other queues. When the name of a model queue is specified in the object descriptor for an MQOPEN, a queue with the attributes of the model is dynamically created. The model itself has no other purpose. If the characteristics of the new queue are to be displayed, the queue would appear to be a local queue.

Temporary dynamic queues exist only until the execution of the program that created it ends (either normally or abnormally), or until the creating program closes it. There is no way to retain a temporary dynamic queue beyond that point. Temporary dynamic queues cannot hold persistent messages.

Permanent dynamic queues are created in the same way, but they are not automatically deleted. They must be explicitly deleted (by specifying a “close” option on delete, or by the administrator issuing a delete command on the queue). Once created, WebSphere MQ does not track dynamically created, permanent dynamic queues.

Which type of dynamic queue is chosen is a matter of application design.


Model queue definition

……

MQOPEN MYMODEL…

Dynamic queue created from the model specifications

Permanent dynamic

Temporarydynamic

OR

• Permanent dynamic ortemporary dynamic

• Other queue characteristics

Application

Model queue MYMODEL definition




Uempty
Instructor notes:
Purpose — To familiarize students with model and dynamic queues.

Details — Model queues are definitions and nothing more.

When the model is opened, a local queue is created dynamically. It assumes the attributes that were defined for the model queue, but is a unique and separate object.

The handle returned from a successful open of a model queue is associated with the dynamically created queue. The model queue is no longer relevant as far as the application program is concerned.

If a responding server application is serving 1000 users, a model queue would avoid the disadvantages of one shared reply-to queue and 1000 reply-to queue definitions.

Temporary dynamic queues may not hold persistent messages. Persistence is not discussed until Unit 3.

Additional information — Many programs or copies of a single program can be running at the same time. And there cannot be more than one queue with the same name within a local queue manager. How do the dynamic queues get names? How does the program know what the name is? How can you ensure uniqueness?

Transition statement — After a queue has been opened, you can write messages to it using the MQPUT call.



Instructor Guide

Figure 2-11. MQPUT call WM101 / VM1011.0

Notes:

Once an application has opened a queue for output, it can call MQPUT to put a message on the queue. The object handle returned by the MQOPEN call is used to identify the queue to be used by the MQPUT call.

Although the figure depicts an application putting a message on a local queue, MQPUT can also be used to put a message to a remote queue. The application must first call MQOPEN to open a local definition of the remote queue, or an alias queue resolving to a local definition of the remote queue. The application must then use the object handle returned by the MQOPEN call.

Those parameters of the MQPUT call that have not been described previously are:

WebSphere MQ message descriptor (input/output): A structure defined in the MQI that provides information about the message accompanying the application data being put on the queue, or returned to the application with the application data when retrieved from a queue. Some of the fields are set by the application that puts the message on the queue, while others are set by


MQPUT callApplication

.

.MQPUT

.

.

Connection

Queuemanager

Access

• Completion code• Reason code

• Connection handle• Object handle• Message descriptor• Put message options• Application data

buffer size• Application data

Call syntax:MQPUT(Hconn, Hobj, MsgDesc, PutMsgOpts, BufferLength, Buffer, CompCode, Reason)




Uempty
the queue manager on behalf of the application. The message descriptor is discussed in more detail in the next unit.
Put message options (input/output) A structure defined in the MQI that contains a number of fields that control the action of MQPUT.

Buffer length (input/output) The size of the application data in the buffer.

Buffer (input) The application data in the message.



Instructor Guide

Instructor notes:

Purpose — To introduce the MQPUT call.

Details — The MQPUT call puts a message on a queue.

If the queue is local, the message is put on the queue. Control is returned to the application once the queue manager has succeeded in putting the message on the queue. If the message is not put onto the queue for any reason, the completion code and reason code returned to the application provide information about what happened.

If the queue is remote, the queue manager puts the message on a transmission queue that is just a local queue with a special purpose. Again, control returns to the application once the queue manager has succeeded in putting the message on the transmission queue or has failed to do so for any reason. Later, and asynchronously to the execution of the application, an MCA gets the message from the transmission queue and sends it across the network to a partner MCA. The partner MCA puts the message on the destination queue.

Transition statement — Now look at how an application gets a message from a queue.




Uempty

Figure 2-12. MQGET call WM101 / VM1011.0

Notes:

An application retrieves a message from a queue by issuing an MQGET call. An application can only issue an MQGET call after it has successfully opened a queue for input (or for browse). The object handle returned by the MQOPEN call is used to identify the queue on the MQGET call.

An application can only get messages from a queue that is owned by the queue manager to which it is connected.

Those parameters of the MQGET call that have not been described previously are:

Get Message Options (input/output) A structure defined in the MQI that contains a number of fields that control the action of MQGET. This structure allows great control over message retrieval. You look at some of those control fields next.

Data length (output) The length of data returned from the call. If data length is less than buffer length, the message is truncated.


MQGET callApplication

.

.MQGET

.

.

Connection

Queue manager

Access

• Message descriptor• Application data• Application data

length• Completion code• Reason code

• Connection handle• Object handle• Get message options• Application data

buffer size

Call syntax:MQGET(Hconn, Hobj, MsgDesc, GetMsgOpts, BufferLength, Buffer, DataLength, CompCode, Reason)



Instructor Guide

Instructor notes:

Purpose — To introduce the MQGET call.

Details — The MQGET is used to get messages from a queue (always a local queue) as well as to browse messages on a queue. The get message options structure contains information that directs the operation of the MQGET.

Transition statement — Now look more closely at one of the parameters on the MQGET call, the get message options structure.




Uempty

Figure 2-13. MQGET get message options WM101 / VM1011.0

Notes:

The MQGET message options structure contains a number of fields that control the action of MQGET. One of the fields, called Options, allows an application to specify one or more of the options listed in the figure, and others that are not listed here. An application can specify more than one option by adding the values together or by combining them using the bitwise OR operation.

The Options field in the MQGET message options structure enables an application to specify one or more of the following parameters.

Wait If the queue is empty, control is not returned to the application. Instead, the application waits until a suitable message arrives.

Set signal If the queue is empty, control is returned to the application. When a suitable message arrives on the queue, the queue manager sends a signal to the application program. In the meantime, the application can continue with other processing and, at some point, either test whether the signal has been set by the queue manager, or wait until the signal is set. Note: Set signal is not available on all platforms.


MQGET get message options

• Wait• Set signal• Browse from start of queue• Browse from current position in queue• Get message under browse cursor• Within sync point control• Outside of sync point control• Accept truncated message• Convert application data



Instructor Guide

Browse from start of queue An application can read the contents of a message on a queue without actually removing it from the queue. This process is known as browsing a message. This option allows an application to browse the first suitable message on a queue.

Browse from current position in queue An application can browse the next suitable message from its current position in the queue.

Get message under browse cursor Having browsed a message, an application can then get the message from the queue, thus removing it from the queue.

Within sync point control An application can get a message under sync point control, in which case the message is not removed from the queue until the unit of work is committed. This option is discussed in a later unit.

Outside of sync point control An application may get a message outside of sync point control. In this case, the message is removed from the queue immediately and cannot be made available again by backing out the unit of work. This option is discussed in Unit 6.

Accept truncated message If a message is too large to fit in the buffer area provided by an application, the application may elect to accept as much of the message as the buffer can hold.

Often, an application knows that a message over a certain size must be an error. To get the other messages in the queue, the application might accept the message in truncated form and put it on a queue that is being used to store messages that require further investigation: a dead letter queue, for example.

Convert application data If an application gets a message that originated on a different system, the application data in the message may use character and numeric representations that are different from the ones being used by the application. The use of this option on an MQGET call causes the application data in a message to be converted into the character and numeric representations being used by the receiving application. This option is discussed further in a later unit.




Uempty
Instructor notes:
Purpose — To introduce the options that control the action of MQGET.

Details — All of the permitted options are discussed in the WebSphere MQ Application Programming Reference. Pick three or four to discuss, such as the Wait, Within sync point control, and Outside of sync point control.

Transition statement — One additional major call remains to be discussed: MQPUT1.



Instructor Guide

Figure 2-14. MQPUT1 call WM101 / VM1011.0

Notes:

The MQPUT1 call is a combination of the MQOPEN, MQPUT, and MQCLOSE calls. MQPUT1 opens a queue, puts a single message on the queue, and then closes the queue, all in a single call. The call syntax is identical to that of MQPUT.

If there is only one message to be put on a queue, the use of MQPUT1 is more efficient than explicitly issuing an MQOPEN call, followed by an MQPUT call, and then an MQCLOSE call. If there is more than one message to be put on a queue, it is less efficient.

The MQPUT1 would be useful in a server application with many client applications sending requests, each with its own reply-to queue. Because the frequency of replies to any one reply-to queue is unpredictable, it may be more appropriate to use MQPUT1 for each reply instead of holding many queues open indefinitely.


MQPUT1 callApplication

.

.MQPUT1

.

.

Connection

Queue manager

AccessAccess

• Completion code• Reason code

• Connection handle• Object descriptor• Message descriptor• Put message

options• Application data

Call syntax:MQPUT1(Hconn, ObjDesc, MsgDesc, PutMsgOpts, BufferLength, Buffer, CompCode, Reason)




Uempty
Instructor notes:
Purpose — To introduce the MQPUT1 call.

Details — The MQPUT1 does save on MQOPEN and MQCLOSE calls. However, each MQPUT1 results in an increased processor usage that is not present on the MQPUT, so the proper use of the call is important.

Transition statement — You have looked at the most often used MQI calls. There are a few more to examine. Although they are not used as frequently, they provide some useful functions. You start with MQINQ.



Instructor Guide

Figure 2-15. MQINQ call WM101 / VM1011.0

Notes:

An MQINQ call can be used by an application to determine the values of specified attributes of a WebSphere MQ object, such as a queue, a topic, a process, a namelist, or the queue manager object. For example, MQINQ can be used by an application to determine the current depth of a queue, or whether triggering is enabled for a queue.

Before an MQINQ call can be issued, the application must first open the object by using an MQOPEN call with the “open for inquiry” option. This requirement is why MQOPEN might be used to open a process definition object, a namelist, or the queue manager object.

Those parameters of the MQINQ call which have not been described previously are:

Attribute selectors (input) An array of the names of the attributes of the object whose values the application wants to retrieve.

Attribute values (output) Two arrays containing the values of the specified attributes. One array contains the values that are integers; the other contains the values that are character data.


MQINQ callApplication

.

.MQINQ

.

.

Queue manager

Queue managerobject

Processdefinition

object

• Attribute values• Completion code• Reason code

• Connection handle• Object handle• Attribute selector

count• Attribute selectors

(some parameters omitted)

Connection

Access

Call syntax:MQINQ (Hconn, Hobj, SelectorCount, Selectors, IntAttrCount, IntAttrs, CharAttrLength, CharAttrs, CompCode, Reason)




Uempty
Some of the parameters listed in the call syntax have been omitted from the description. Selectors are passed to the call as integers or characters, depending on the individual selector; the additional parameters in the call syntax reflect those specific selector parameters.


Instructor Guide

Instructor notes:

Purpose — To describe the MQINQ call.

Details — You are being simplistic in the description of the selectors and the returned values. This topic can be confusing; if anyone wants to get into a deep discussion, take them offline. An in-depth discussion of MQINQ is out of scope for an introductory class. Suggest they look at the samples supplied with their platform, as well as the appendixes in the WebSphere MQ Application Programming Guide, for examples of how to code this call.

Transition statement — Having inquired on the attributes of a queue by using MQINQ, an application might want to change some of them. To accomplish this task, it uses the MQSET call.




Uempty

Figure 2-16. MQSET call WM101 / VM1011.0

Notes:

MQSET can be used to modify a subset of attributes of a local queue. The attributes that can be set are:

• Whether put requests are allowed for the queue (InhibitPut) • Whether get requests are allowed for the queue (InhibitGet) • The attributes associated with triggering (TriggerControl, TriggerType,

TriggerMsgPriority, TriggerDepth, and TriggerData) • Whether distribution list messages can be put on the queue (DistLists) (not applicable

for z/OS)

MQSET cannot be used to change any attributes of other objects.


MQSET callApplication

.

.MQSET

.

.

Connection

Queuemanager

Access• Completion

code• Reason code

• Connection handle• Object handle• Attribute selector

count• Attribute selectors

(some parameters omitted)

Call syntax:MQSET (Hconn, Hobj, SelectorCount, Selectors, IntAttrCount, IntAttrs, CharAttrLength, CharAttrs, CompCode, Reason)



Instructor Guide

Instructor notes:

Purpose — To describe the MQSET call.

Details — Again, do not let this explanation get too deep. If necessary, point them to the samples and the manuals.

When depth triggering is specified for an application queue and a trigger event occurs, the queue manager prevents any further trigger events associated with that queue by setting the attribute TriggerControl to MQTC_OFF. One use of the MQSET call, therefore, is to allow an application that is started to service the application queue to reset the attribute TriggerControl to MQTC_ON before it terminates.

Transition statement — There are three remaining MQI calls: MQBEGIN, MQCMIT, and MQBACK, which you have not yet discussed.




Uempty

Figure 2-17. Additional MQI calls WM101 / VM1011.0

Notes:

MQBEGIN, MQCMIT, MQBACK, MQSUB, and MQSUBRQ are the remaining calls. They are discussed in detail in Unit 6, “Transactional Support.” As an overview:

• MQBEGIN is used to allow queue managers to coordinate updates that can include other resource managers.

• MQCMIT: If the queue manager is permitted to coordinate its own updates or the updates of other resource managers, MQCMIT finalizes those updates and commit the pending GET and PUT operations, and in-scope database updates.

• MQBACK: If the queue manager is permitted to coordinate its own updates or the updates of other resource managers, MQBACK backs out any pending GET and PUT operations and in-scope database updates. MQBACK backs out to a point of known consistency.


Additional MQI calls

• MQBEGINBegin a unit of work that is coordinated by the queue manager, and that can involve external resource managers

• MQCMITFinalize updates and commit the pending GET and PUT operations, as well as in-scope database updates

• MQBACKBack out any pending GET and PUT operations, as well as in-scope database updates, to a point of known consistency

• MQSUBRegister subscription to a particular topic

• MQSUBRQMake a request for a subscription, when the subscriber has been registered with MQSO_PUBLICATIONS_ON_REQUEST



Instructor Guide

Instructor notes:

Purpose — Introduce the other MQI calls.

Details — The “other resource managers” mentioned are presently only database managers (and only a subset of them). The supported resource managers might change with later releases, but make no promises.

When you say permitted to coordinate, you mean that the queue manager cannot coordinate if there is another unit-of-work manager being used, for example, CICS, ENCINA, or TUXEDO.

On the OS/400, the MQBACK and MQCMIT calls are not supported for applications running in compatibility mode.

On z/OS, the MQBACK and MQCMIT calls are used only by batch programs.

Transition statement — Now you have looked at the native MQI calls. See how they are implemented in the Java environment.




Uempty

Figure 2-18. Connecting to a queue manager with Java WM101 / VM1011.0

Notes:

To connect to a queue manager, all you need to do is create an instance of the MQQueueManager class. For example,

MQQueueManager queueManager = new MQQueueManager("QM1");

If the queue manager name is left blank (null or ""), a connection is made to the default queue manager.

MQQueueManager is the Java constructor method equivalent of the MQCONN call. There are multiple formats of this call, depending on which parameters are passed.


Connecting to a queue manager with Java

Queue managerQM1

MQQueueManager queueManager = new MQQueueManager(String queueManagerName);

Program

queueManager



Instructor Guide

Instructor notes:

Purpose — Give the Java syntax to connect to a queue manager. This syntax is the Java implementation of the MQCONN call.

Details — This slide and the next series of slides show how the concepts discussed in the previous topic are applied to Java and JMS. Applications that use Java or JMS need to perform the same MQI functions, but they use different methods. The message is now in the MQMessage variables (MQMD) and MQMessage buffer (application data). The “common API” concept is what you are conveying here — that the same set of MQI calls is used, regardless of the environment.

Show that connecting to a queue manager creates a queue manager object.


Transition statement — How do you get access to a queue?




Uempty

Figure 2-19. Accessing queues with Java WM101 / VM1011.0

Notes:

Queues are accessed using the accessQueue method of the MQQueueManager class.

The accessQueue method returns a new object of class MQQueue. For example, to open queue QM1.A on queue manager QM1, use the following code:

MQQueue myQueue = MQQueueManager.AccessQueue("QM1.A”,MQC.MQOO_OUTPUT,"QM1","dynamicQName","altUserID");

AccessQueue is the Java method equivalent of the MQOPEN call.

With WebSphere classes for Java, you can also create a queue object using the MQQueue constructor. The parameters are the same as for the accessQueue method, with the addition of a queue manager parameter.


Accessing queues with Java

Program Queue managerQM1

myQueue

MQQueue myQueue = new MQQueueManager(String MQQueueManager,

String queueName,int openOptions,String queueManagerName,String dynamicQueueName,String alternateUserId);

QueueQM1.A



Instructor Guide

Example:

MQQueue queue = new MQQueue(queueManager,"qName",MQC.MQOO_OUTPUT,"qMgrName","dynamicQName","altUserID");




Uempty
Instructor notes:
Purpose — Explain how to access a queue.

Details — Show how a Java MQQueue object is created when accessing a queue, and explain how this object is used to handle the queue.


Transition statement — How does Java provide the MQMD and application data?



Instructor Guide

Figure 2-20. The Java MQMessage object WM101 / VM1011.0

Notes:

The MQMessage object represents the message descriptor as variables and the user message data as the buffer.

A group of ReadXXXX methods is provided by the Java API for reading various data types from a message. A similar group of WriteXXXX methods is provided for writing data of various data types into a message. The format of numbers and strings used by these read and write methods can be controlled by the encoding and characterSet member variables.

The remaining member variables contain control information that accompanies the application message data when a message travels between sending and receiving applications. The application can set values into the member variable before putting a message to a queue and can read values after retrieving a message from a queue.


The Java MQMessage object

• Represents message descriptor as variables, and the user message data as the buffer

• Application can set values into the member variable before putting a message to a queue, and can read values after retrieving a message from a queue

MQMessage

MQMessage variables MQMessage buffer




Uempty
Instructor notes:
Purpose — Describe the MQMessage object, and how data is read from and written to it.

Details — Explain what is meant by ReadXXXX and WriteXXXX.


Transition statement — After the message object has been populated, you can MQPUT it.



Instructor Guide

Figure 2-21. Putting messages on the queue with Java WM101 / VM1011.0

Notes:

The put method puts a message onto the specified queue. It takes an MQMessage object as the first parameter and the put message options object as the second parameter.

The put method uses these objects to construct the underlying MQI MQPUT call. There are multiple formats of this call, depending on which parameters are passed.

The variables of the MQMessage object are used to construct the message descriptor, and they are updated on successful completion of the put request.

To put a message on a queue, the queue must first have been opened with the “output” option.


Putting messages on the queue with Java

Program Queue manager QM1

MQMessageQueueQM1.A

(opened for output)

put()

myQueue.put(myMessage,myPMO);




Uempty
Instructor notes:
Purpose — Introduce putting messages.

Details — Go through the whole process again, from connecting to a queue manager to putting a message onto the queue.


Transition statement — Next: how you get a message from the queue.



Instructor Guide

Figure 2-22. Getting messages from the queue with Java WM101 / VM1011.0

Notes:

The get method retrieves a message from the associated queue. The call takes an MQMessage object as the first parameter, a list of get options, and other optional parameters. A number of fields in the MQMessage object are treated as input, in the processing performed by the underlying queue manager in response to the get request.

If the GET throws an MQException and sets the associated completion code to “failed,” the fields (member variables) and message buffer of the MQMessage object are unchanged. In this case, no message has been returned. If the GET request sets the completion code to “warning,” the message fields and the message buffer of the associated MQMessage object are replaced with the message descriptor and message data from the incoming message.

The second parameter of the get method is the name of the associated getMessageOptions object. The fields of this object control the actions of the MQGET request. In particular, the options field controls the type of get request, and another field controls the method of message identification.


Getting messages from the queue with Java

Program Queue manager QM1

QueueQM1.A

(opened for input)

get()

myQueue.get(myMessage, myGetOptions,buffsz);

MyMessage




Uempty
Other fields within the getMessageOptions object are updated upon successful completion of the get request.
The third parameter of the get request is the size of the largest message that can be returned by this request. If a value is not supplied, the default action is to adjust the size of the buffer of the specified MQMessage object to accommodate the selected message. The parameter can be used to restrict the size of the message buffer, and stop a large message from being returned. This parameter overrides the default size and any value set by the resizeBuffer request.

There are multiple formats of this call, depending on which parameters are passed.

To get a message from a queue, the queue must first have been opened with the “input” option.



Instructor Guide

Instructor notes:

Purpose — Demonstrate what needs to be done to retrieve a message from a queue.

Details — Go through the whole process in detail, so that the students can visualize how the process works.


Transition statement — Now, look at these functions as they are implemented using JMS.




Uempty

Figure 2-23. Introducing Java Message Service (JMS) WM101 / VM1011.0

Notes:

JMS is a collection of Java services used to process messages. It is an open standard designed for communicating with enterprise messaging systems.

Since messaging is peer-to-peer, all users of JMS are referred to generically as clients. A JMS application is made up of a set of application-defined messages and a set of clients that exchange them.


Introducing Java Message Service (JMS)

• JMS is a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise messaging product.

• JMS provides a common way for Java programs to create, send, receive, and read messages to and from an enterprise messaging system.

• JMS API is a standard developed by Sun, IBM, and other enterprise solution vendors.

• WebSphere MQ is a JMS provider that implements JMS for a messaging product.



Instructor Guide

Instructor notes:

Purpose — Introduce JMS.

Details —






Uempty

Figure 2-24. JMS concept WM101 / VM1011.0

Notes:

WebSphere MQ classes for Java Message Service are a set of Java classes. They implement the Oracle JMS interfaces to enable JMS programs to access WebSphere MQ systems. Both the point-to-point and publish/subscribe models of JMS are supported.


JMS concept

Enterprise messaging system

JMS client

messages

JMS client

messages

JMS client

messages



Instructor Guide

Instructor notes:

Purpose — To give more information about JMS and the IBM WebSphere MQ implementation.

Details —






Uempty

Figure 2-25. JMS APIs WM101 / VM1011.0

Notes:

In standard WebSphere MQ terms:

• Connection provides a scope for temporary queues, and a place to hold the parameters that control how to connect to WebSphere MQ. An example of a connection parameter is the name of the remote host if you are using the WebSphere MQ Java client connectivity.

• Session contains an HCONN (connection handle) and defines a transactional scope.

• MessageProducer and MessageConsumer contain an HOBJ (queue handle) that specifies a particular queue for writing to or reading from.


JMS APIs

• Generic JMS model is based around the following interfaces that are defined in the javax.jms package from Oracle:– Connection

Provides access to the underlying transport, and is used to create sessions– Session

Provides a context for producing and consuming messages, including the methods used to create MessageProducers and MessageConsumers

– MessageProducerUsed to send messages

– MessageConsumerUsed to receive messages



Instructor Guide

Instructor notes:

Purpose — To introduce the JMS model.

Details — This figure only introduces some of the interfaces of the JMS package. They are explained on the next few visuals.


Transition statement — Now you look at the JMS components.




Uempty

Figure 2-26. JMS components WM101 / VM1011.0

Notes:

JMS provider is the entity that implements JMS for a messaging product.

JMS messages: JMS defines a set of message interfaces. Clients use the message implementations supplied by their JMS provider. A major goal of JMS is that clients have a consistent API for creating and working with messages, which are independent of the JMS provider.

JMS domains: Messaging products can be broadly classified as either point-to-point or publish/subscribe systems. Point-to-point products are built around the concept of message queues. Publish/subscribe clients address messages to some node in a content hierarchy. Publishers and subscribers are generally anonymous, and may dynamically publish or subscribe to the content hierarchy.


JMS components

Messaging provider

JMS clientJMS client

Publish topic

JMS messageJMS interface

Point-to-point domain Publish/subscribe domain

JMS message



Instructor Guide

Instructor notes:

Purpose — To introduce messages, providers, and domains.

Details — The domains are explained in detail later.






Uempty

Figure 2-27. Relationship to other Java APIs WM101 / VM1011.0

Notes:

JMS is a mandatory part of J2EE (Java 2 Enterprise Edition), and must be available to:

• Application code running in the web container using the JSP and servlet programming models.

• The EJB container using the EJB programming model.

• The client container using the Java 2 Platform, Standard Edition (J2SE) programming model.

The implementation must allow code running in the three containers to intercommunicate using messaging.


Relationship to other Java APIs

Application server

Web container

JSP Servlet

J2SEJMS

EJB container

EJB

Applet container

J2SE

Applet

Application clientcontainer

Applicationclient Database

JAASJTA

Java mailJAFJAXP

ConnectorsJDBC

J2SE

JMSJAASJAXPJDBC

J2SEJMSJAASJTA

Java mailJAFJAXP

ConnectorsJDBC



Instructor Guide

Instructor notes:

Purpose — To show the required relationships of architectural elements of the J2EE (Java 2 Enterprise Edition) platform.

Details —

Additional information — The J2EE standard services shown in the figure are:

JMS: Java Message Service

JAAS: Java Authentication and Authorization Service

JTA: Java Transaction API

JavaMail: JavaMail API

JAF: JavaBeans Activation Framework

JAXP: Java API for XML Parsing

JDBC: Java Database Connectivity API

Connectors: J2EE Connector Architecture

J2SE: Java 2 Platform, Standard Edition

Transition statement — Look at the IBM JMS providers.




Uempty

Figure 2-28. WebSphere MQ APIs WM101 / VM1011.0

Notes:

The JMS interface is presented to application developers, but the underlying services are supplied by the WebSphere MQ base classes for Java, which in turn use the services of the standard MQI.

A Java application could also be written using the WebSphere MQ base classes for Java. This approach allows for portability across other messaging product implementations.

JMS and WebSphere MQ base classes are object-oriented implementations of WebSphere MQ functionality. The standard MQI APIs are essentially a procedural language implementation. In some of the supported language bindings, there may be a choice of an object-oriented or a procedural interface. Java only has object-oriented style interfaces.


WebSphere MQ APIs

Application

Queue manager

MQI

Base classes for Java

Provider classes

JMS



Instructor Guide

Instructor notes:

Purpose — Shows all available WebSphere MQ APIs and their relationship.

Details —






Uempty


Notes:

This unit offered a brief look at each of the verbs. In the next unit, some of the unique functions available using the MQI are reviewed. It is important to note that, although there are a limited number of MQI verbs, they are powerful and offer a great deal of flexibility.

With appropriate design consideration, a program can be designed so that it can easily be moved among the various supported platforms with little or no change.


Unit summary

Having completed this unit, you should be able to:• Explain several calls provided by the MQI• Explain the use of several calls at a high level• Describe the details of the MQI• Describe the Java interface and Java Message Service (JMS) in

WebSphere MQ



Instructor Guide

Instructor notes:

Purpose — Provide a review of the MQI.

Details — At first glance, the MQI might appear to be straightforward. It is simple to code the actual calls. Despite the simplicity, however, MQI an industrial-strength interface that allows applications running in even the largest IT enterprises to take advantage of the benefits of a messaging and queuing solution.

Transition statement — The unit checkpoint questions are next.




Uempty

Figure 2-30. Checkpoint questions WM101 / VM1011.0

Notes:

1. The additional parameter used on the MQCONNX call is:

a. Queue manager name.b. Connection handle.c. Connection options.d. Reason code.

2. True or False: MQSET lets you change all the attributes of queues only.

3. Select all that apply: You must use MQOPEN before using:

a. MQGET.b. MQINC.c. MQPUT1.d. MQCLOSE.e. All of the above.


Checkpoint questions

1. The additional parameter used on the MQCONNX call is the: a. Queue manager name.b. Connection handle.c. Connection options.d. Reason code.


3. You must use MQOPEN before using (select all that apply): a. MQGET.b. MQINQ.c. MQPUT1.d. MQCLOSE.e. All of the above.



Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty

Figure 2-31. Checkpoint answers WM101 / VM1011.0

Notes:

1. The additional parameter used on the MQCONNX call is:

a. Queue manager name.b. Connection handle.c. Connection options.d. Reason code.

Answer: c. Connection options allow the program to specify normal or fast path bindings. It also allows certain clients to specify a particular connection to use at run time.


Answer: False. MQSET can be used only to modify certain attributes of queues.

3. Select all that apply: You must use MQOPEN before using:

a. MQGET.b. MQINC.c. MQPUT1.


Checkpoint answers

1. The additional parameter used on the MQCONNX call is the: a. Queue manager name.b. Connection handle.c. Connection options.d. Reason code.Answer: c. Connection options allow the program to specify normal or fast path

bindings. It also allows certain clients to specify a particular connection to use at run time.

2. True or False: MQSET lets you change all the attributes of queues only. Answer: False. MQSET can be used only to modify certain attributes of queues.

3. You must use MQOPEN before using (select all that apply): a. MQGET.b. MQINQ.c. MQPUT1.d. MQCLOSE.e. All of the above.Answer: a, b, and d. MQPUT1 never requires an MQOPEN.



Instructor Guide

d. MQCLOSE.e. All of the above.

Answer: a, b, and d. MQPUT1 never requires an MQOPEN.




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide




Uempty
Unit 3. Messages: additional information
Estimated time

00:30


This unit describes some of the fields in the message descriptor and additional message options.



• Describe some of the fields in the message descriptor and how they relate to the message queue environment

• Explain the various orders in which messages can be retrieved from a queue

• Describe message groups and segmentation and why they are used

• Describe distribution lists



References



© Copyright IBM Corp. 2011 Unit 3. Messages: additional information 3-1

Instructor Guide


Notes:


Unit objectives

After completing this unit, you should be able to:• Describe some of the fields in the message descriptor and how they

relate to the message queue environment• Explain the various orders in which messages can be retrieved from a

queue• Describe message groups and segmentation and why they are used• Describe distribution lists




Uempty

Figure 3-2. Some fields in the message descriptor WM101 / VM1011.0

Notes:

Recall that a message is composed of two parts: the message descriptor and the application data. The message descriptor contains a number of fields, some of which are shown in this figure. The fields listed here are discussed in more detail.

Every message contains a message identifier, which is determined by the value of the field Msgld in its message descriptor. When an application puts a message on a queue, either the application can supply a message identifier or it can ask the queue manager to generate a unique one.

The correlation identifier is normally used to provide an application with some means of matching a reply with the original message. In a reply message, therefore, the value of the Correlld field is normally copied from the Msgld field of the original message.

The last three fields are associated with application data conversion, and the following description is a brief explanation of their meanings:

Format The format of the application data in the message


Some fields in the message descriptor

• Persistence• Priority• MsgId• CorrelId• Report• Feedback• ReplyToQ• ReplyToQMgr

Application dataMessage descriptor

• Expiry• GroupId• MsgSeqNumber• Offset• Format• Encoding• CodedCharSetId

Message descriptor fields

• SubName• SubUserData• SubCorrelId• PubPriority• PubAccountingToken• PubAppIdentityData

SubLevel• ResObjString

Publication/subscription message descriptor fields



Instructor Guide

Encoding The representation used for the binary integers, packed decimal integers, and floating point numbers in the application data

CodedCharSetId The representation used for the character data in the application data

The publish/subscribe message descriptor fields enable the creation of published information at a topic level destined to all applications that subscribe to the topic.




Uempty
Instructor notes:
Purpose — To review the concept of a message descriptor and to introduce some of its fields.

Details — The figure could be used to revisit the fact that a message has two parts, the message descriptor and the application data.

At this stage, it is probably not worth describing any of the fields in detail, as all but the last three are about to be explained in the remainder of this topic. The data conversion fields are covered in depth in the Application Programming course and can be found in the WebSphere MQ Application Programming Guide and WebSphere MQ Application Programming Reference manuals.

Additional information — Added the publish/subscribe message descriptor information.

Transition statement — Begin with the first field on the list, Persistence.



Instructor Guide

Figure 3-3. Message persistence WM101 / VM1011.0

Notes:

A message is said to be persistent if it survives a queue manager restart. Persistence applies whether the queue manager is stopped by an operator command or because of a system failure. Persistent messages must be written to a log. If a queue manager is restarted after a failure, it recovers these persistent messages as necessary from the logged data.

A message is said to be nonpersistent if it does not survive a queue manager restart. This definition applies even if a queue manager finds an intact nonpersistent message on disk during restart; by default, the queue manager discards it. On non-z/OS queue managers, if a queue is set to NPMCLASS(HIGH), the queue manager does its best to rebuild all messages, even non-persistent ones. On z/OS systems nonpersistent messages are always discarded.

The persistence of a message is determined by the value of the Persistence field in its message descriptor.

Both persistent and nonpersistent messages can be stored on the same queue.


Message persistence

Log

CC/RC

Persistentmessage

CC/RC

Non-persistentmessage

ApplicationQueue

manager




Uempty
Instructor notes:
Purpose — To introduce the concept of message persistence and the requirement for a log.

Details — Whether to make a message persistent or nonpersistent, is an application design decision. Most messages in most systems must always be delivered, but there may be others that could be regenerated automatically after a system crash or a planned restart.

Nonpersistent messages can be used for better performance when it is not critical for messages to be able to survive a queue manager restart.


Transition statement — Next, you look at the order in which messages are retrieved from a queue.



Instructor Guide

Figure 3-4. Retrieval in priority order WM101 / VM1011.0

Notes:

When a message is put on a queue, the application can set the Priority field in the message descriptor to a value in the range 0 (lowest priority) to 9 (highest priority). If no value is specified, the value of the DefaultPriority attribute of the queue is assigned to the message.

The value of the MsgDeliverySequence attribute of a queue determines how messages are placed in the queue. If the MsgDeliverySequence is priority, the message is enqueued according to the value of the Priority field in the MQMD, with messages of the same priority being enqueued in FIFO (first-in first-out) order. If the MsgDeliverySequence is FIFO, messages are enqueued in FIFO order at the priority specified by the DefaultPriority attribute of the queue.

The value of the MsgDeliverySequence attribute of the queue at the time that messages are placed on the queue thus determines the order in which they are retrieved from the queue.


Retrieval in priority order

msg A

priority2

msg B

priority0

msg C

priority1

msg D

priority0

msg E

priority2

msg F

priority1

msg G

priority2

Order of message arrival:first last

msg A

priority2

msg B

priority0

msg C

priority1

msg D

priority0

msg E

priority2

msg F

priority1

msg G

priority2

Enqueue order with MsgDeliverySequence = FIFO:

msg A

priority2

msg B

priority0

msg C

priority1

msg D

priority0

msg E

priority2

msg F

priority1

msg G

priority2

Enqueue order with MsgDeliverySequence = PRIORITY:




Uempty
Instructor notes:
Purpose — Explain how message priority is implemented. The order in which messages are retrieved from the queue depends on the order that messages are put onto the queue. The order is determined by the queue MsgDeliverySequence and the priority assigned to each message, if priority order is specified.

Details — In the figure, messages arrive at the queue in the order specified in the uppermost box. The value of MsgDeliverySequence determines the order in which the messages are stored in the queue. If MsgDeliverySequence is set to FIFO, messages are put on the queue (enqueued) in first-in, first-out sequence, exactly in the order they arrive. If MsgDeliverySequence is set to PRIORITY, messages are enqueued in priority order, highest priority first, and first-in, first-out within a given priority.

If the MsgDeliverySequence and DefPriority (the queue default message priority attribute) are altered while messages are in the queue, the messages might not be retrieved in the expected order. The WebSphere MQ Application Programming Guide explains the effect of changing those attributes.

An exception is where an application is browsing a queue using successive MQGET calls with the browse next option. The application has browsed all the messages with priority 2 and has started to browse messages with priority 1. In this case, any message with priority 2 that is put on the queue later is not seen by the application unless it issues an MQGET call with the browse first option. The browse first option repositions the browse cursor on the first message in the queue, and begins to browse the queue again.


Transition statement — Next, you look at responses and reports.



Instructor Guide

Figure 3-5. Report field and report message type WM101 / VM1011.0

Notes:

Say, for example, that an application issues an MQPUT call for a message destined for a remote queue and a problem is detected during the call. The queue manager reports the problem to the application immediately with a completion code and reason code.

If a problem occurs during the delivery of the message, the queue manager can generate a report message and send it to the reply-to queue specified in the message descriptor of the original message. The queue manager can also report on certain other events associated with the delivery of the message, in this way.

An application does not receive report messages by default. It must request them. It requests a report when it puts a message on a queue by specifying which reports it wants to receive in the Report field in the message descriptor. If more than one type of report is required, the values can be added or combined using the bitwise OR operation.

The following are some of the types of reports that can be requested:

• Exception The queue manager generates an exception report if a message cannot be handled in


Report field and report message type

Destinationqueue

Transmission queue

Reply-to queue

CC/RC

Remote queue definition

Reports• Exception• Expiration• COA• COD

Application Local queue manager


MQOPEN

CC/RCMQPUT




Uempty
any way; for example, the message cannot be put on the destination queue because the queue is full.
Confirm on arrival (COA) The queue manager generates a COA report when a message is put on the destination queue.

Confirm on delivery (COD) The queue manager generates a COD report when a message is delivered to the receiving application.

Expiration The queue manager generates an expiration report if a message is discarded before delivery because its expiry time has passed. You examine expiry later in this unit.

COA and COD reports can be used to implement non-repudiation functions within an application. For example, a COA and COD report could preven a customer from claiming that a bill was never received or a bank from denying that a money transfer arrived. Such functionality may be more trusted when the basic mechanism is provided by the underlying system, WebSphere MQ, rather than by the application itself.

In a report message, the Feedback field in the message descriptor indicates the nature of the report (for example, COA report or COD report) or, for an exception report, the reason for the report. For example, the destination queue is full, the message is too significant for the destination queue.

This example is a second use of the fields ReplyToQ and ReplyToQMgr in the message descriptor. Earlier in the course, you saw that these fields can also be used by a server application to determine where a reply message is sent.



Instructor Guide

Instructor notes:

Purpose — To introduce report messages.

Details — There are additional report options. The additional report options are covered in detail in the Application Programming course as well as the WebSphere MQ Application Programming Reference.


Transition statement — What can be done if there is a business requirement for a message to be discarded, but it cannot be delivered within a specified time? You now see that WebSphere MQ provides a function to support this requirement.




Uempty

Figure 3-6. Expiry WM101 / VM1011.0

Notes:

When an application puts a message on a queue, it can set an expiration time for the message in the Expiry field of the message descriptor. The Expiry value is a time expressed in tenths of a second. It specifies the total amount of time that the message can spend on the destination queue and also on any transmission queues, if the message is put to a remote queue.

When the receiving application attempts to get the message from the destination queue, the queue manager subtracts the time the message has been on the queue from the Expiry value in the message descriptor. If the resulting value is zero or negative, the message is not returned to the application; instead, it becomes eligible to be discarded. The next suitable message in the delivery sequence for the queue is returned to the application instead.

If it has been requested, an expiration report is sent to the reply-to queue as specified in the message descriptor of the expired message.


Expiry

Application A Application BMQPUT MQGET

Expiredmessages



Instructor Guide

The queue manager does not immediately purge expired messages. When a message has expired, the queue manager purges it the next time it processes an MQGET call. The WebSphere MQ administrator can also configure the queue manager to scan periodically for expired messages and discard them instead of waiting for an MQGET call to be processed.

There is no need for clocks to be synchronized across a network of queue managers for this feature to work.




Uempty
Instructor notes:
Purpose — To explain the concept of expiry time.

Details — Expiry works in the following way. The queue manager subtracts the value in the Expiry field to reflect the time the message spends on the destination queue and also on any intermediate transmission queues. When the message is eventually retrieved by an application from the destination queue, the value in the Expiry field represents the amount of the original expiry time that remains.

A message whose expiry time has elapsed may not be discarded immediately. The queue manager performs this task asynchronously. An expiration report, if requested, is only sent when the message is discarded, not when it becomes eligible to be discarded.

Expiry time can be used by an application when the business requirement is such that a message ceases to have any business significance after a certain time. For example, a message from a retail outlet to a centralized credit card system requests authorization for a transaction. It might specify an expiry time of only a few minutes if it cannot be authorized within a reasonable time.


Transition statement — What if a message is too large for the queue, queue manager, or receiving application program? IBM WebSphere MQ allows messages to be segmented into smaller pieces.



Instructor Guide

Figure 3-7. Message groups WM101 / VM1011.0

Notes:

Messages can occur within logical groups. Logical groups allow for individual messages to be processed in a specific order. A group is the highest level in the hierarchy, and is identified by a GroupId. It consists of one or more messages that contain the same GroupId. These messages can be stored anywhere in the queue, not necessarily in physical consecutive order. Each message within a group consists of one physical message, unless it is split into segments. Each message is logically separate from the others; messages in a group are related to other messages within the same group by their GroupId and MessageSeqNumber fields.


Message groups

• Message group consists of one or more logical messages

• Logical message is:– A physical message (unless it is split into segments)– Identified by the GroupId and MsgSeqNumber fields in the message

descriptor• A message group is needed to:

– Ensure ordering on retrieval (where it is not already guaranteed)– Allow an application to group together related messages

• Segmentation and reassembly can be done by the application or by the queue manager

Message group

Segment 1

Logical message 1

Logical message 2

Logical message 3

Segment 2




Uempty
Instructor notes:
Purpose — To explain the concepts of a message group and a logical message, and why they are needed.

Details — A message group is a group of one or more logical messages.

A logical message is a physical message, unless it is split into segments. You look at message segmentation a little later. For the moment, therefore, you assume that a logical message is a physical message.

A logical message within a group is identified by two fields in the message descriptor, GroupId and MsgSeqNumber. All logical messages belonging to the same group have the same value for the GroupId field. The MsgSeqNumber field has the value 1 for the first logical message, 2 for the second, and so on. There is therefore an implied ordering of the logical messages within a group.

A physical message that does not belong to any group has the value MQGI_NONE in the GroupId field, and the value 1 in the MsgSeqNumber field.

There are two main uses of a message group.

• To ensure ordering on retrieval in circumstances where ordering on retrieval is not already guaranteed.

An application is able to put a sequence of messages constituting a message group on a queue by specifying the put message option MQPMO_LOGICAL_ORDER. The queue manager generates a unique group identifier and assigns a message sequence number to each message as it is put on the queue.

Another application is then able to get the messages constituting the group from the queue, in the same order they were put, by specifying the get message option MQGMO_LOGICAL_ORDER.

• To allow an application to group together related messages.

This feature can be useful if it is important for a group of related messages to be processed by the same server instance, or by a particular server instance. By setting the value MQMO_MATCH_GROUP_ID in the MatchOptions field in get message options, an application can retrieve only those messages with a specified group identifier.

A logical message may consist of two or more physical messages, each of which is called a segment. A segment of a logical message is identified by three fields in the message descriptor: Groupld, MsqSeqNumber, and Offset.

All segments of the same logical message have the same values for the Groupld and the MsgSeqNumber fields, but the value of the Offset field is different for each segment. The segment offset is the offset of the data in the physical message from the start of the logical message. The offset of the first segment is 0.



Instructor Guide

Additional information — Segmented messages are not supported by IBM WebSphere MQ publish/subscribe. A segmented message sent to a publication broker is rejected as invalid.

Message segmentation is not supported in the z/OS environment.

All the MQPUT calls that place segments of a message on a queue take place within a single unit of work. The same is true of MQGET calls that receive segmented messages. A single unit of work reduces the possibility of incomplete work groups being present in the network at any given time.


Transition statement — Now look at how WebSphere MQ can support an application that needs to send the same message to multiple destinations.




Uempty

Figure 3-8. Message segmentation WM101 / VM1011.0

Notes:

A message may be too large for a queue or queue manager to handle in a single buffer because of the way that the queue or queue manager is configured. A receiving application may also not be able to handle an entire large message at once. In either case, the message can be segmented into smaller pieces. The sending application can perform the segmentation itself and then issue an MQPUT call for each segment; the receiving application then issues an MQGET call for each segment. An application can also issue a single MQPUT call and allow the queue manager to segment the message on behalf of the application. When the receiving application issues the MQGET to retrieve the message, the queue manager reassembles it before returning it to the application.


Message segmentation

• Message too large for queue, queue manager, or application can be segmented• Segmentation performed by queue manager or by application

Message group

Segment 1

Logical message 1

Logical message 2

Logical message 3

Segment 2

Large message



Instructor Guide

Instructor notes:

Purpose — To explain the use of segmentation for a large message.

Details — A segment of a message is identified by three fields in the message descriptor: Groupld, MsqSeqNumber, and Offset. Each segment of a message consists of one physical message that might belong to a group. A segment is logically part of a single message, so only the MsgId, Offset, and SegmentFlag fields in the MQMD should differ between separate segments of the same message.

All segments of the same logical message have the same values for the Groupld and the MsgSeqNumber fields, but the value of the Offset field is different for each segment. The segment offset is the offset of the data in the physical message from the start of the logical message. The offset of the first segment is 0.

The application itself may segment the message, and then place each segment in the queue with separate MQPUT calls, in which case the receiving application must receive each segment via separate MQGET calls. The application can also issue an MQPUT for the entire message and let the queue manager segment the message for the application. If the message is segmented, the receiving application issues a single MQGET and the queue manager reassembles the message before delivery.


Transition statement — Segmentation can also be used to ensure that a receiving application retrieves messages from the queue in the same order they were placed on the queue by a sending application.




Uempty

Figure 3-9. Distribution list WM101 / VM1011.0

Notes:

A distribution list allows an application to put a message to multiple destinations using a single MQPUT call.

The application first opens a distribution list using an MQOPEN call. Once a distribution list has been opened, the application can call MQPUT to put a message on the queues in the list. The queue manager responds by putting one copy of the message on each local queue, including the transmission queues. Thus, in the example depicted in the figure, only one copy of the message is put on the transmission queue DALLAS, even though the message is ultimately destined for two queues.

An important property of the implementation is that a message destined for multiple queues is only replicated at the last possible point at each stage of its journey. In this way, network traffic is minimized.


Queue manager QM1 (local)

Distribution listCALL MQOPEN…

CALL MQPUT…

MAIL_IN

DALLAS

PARIS

Queue manager DALLAS(remote)

MAIL_IN

SEATTLEDistribution list

??

QM1.DALLAS(DALLAS.SEATTLE)

DALLASMAIL_IN_SEATTLE

QM1.DALLAS(DALLAS.MAIL_IN)

DALLASMAIL_IN_DALLAS

QM1.PARIS(PARIS.MAIL_IN)

PARISMAIL_IN_PARIS

QM1.MAIL_IN(local)

MAIL_IN_Q1

Resolves toQMgrNameObjectName

Queue manager PARIS(remote)

MAIL_IN



Instructor Guide

Instructor notes:

Purpose — Explain what a distribution list is and how it works.

Details — A distribution list allows an application to put a message to multiple destinations using a single MQPUT call. It works in the following way.

The application first opens a distribution list using an MQOPEN call. A distribution list is a set of object records, where each object record has two fields, ObjectName and ObjectQMgrName, specifying the queue name and the queue manager name of a single destination queue.

A distribution list may contain the name of an alias queue or the name of a local definition of a remote queue. In the example of a distribution list shown in the figure, the following are assumed.

• MAIL_IN_Q1 is a local queue MAIL_IN on queue manager QM1. • MAIL_IN_PARIS is a remote queue definition that resolves to the queue MAIL_IN on

queue manager PARIS using transmission queue PARIS. • MAIL_IN_DALLAS is a remote queue definition that resolves to the queue MAIL_IN on

queue manager DALLAS using transmission queue DALLAS. • MAIL_IN_SEATTLE is a remote queue definition that resolves to the queue MAIL_IN on

queue manager SEATTLE using transmission queue DALLAS.

Once a distribution list has been opened, the application can call MQPUT to put a message on the queues in the list. As a response to the call, the queue manager puts one copy of the message on each local queue (including the transmission queues). Thus, only one copy of the message is put on the transmission queue DALLAS even though the message is ultimately destined for two queues.

On the transmission queue, the application data is prefixed by a distribution header, as well as a transmission queue header. Appended to the distribution header are object records for MAIL_IN at DALLAS and MAIL_IN at SEATTLE. Thus, the message that is transmitted between QM1 and DALLAS effectively contains a distribution list for the two destinations. Therefore, when the message is received by the receiving MCA at DALLAS, the MCA has sufficient information to open a distribution list and put the message to it. The queue manager puts one copy of the message on the local queue MAIL_IN and another copy on the transmission queue SEATTLE.

An important property to note about the implementation is that a message destined for multiple queues is only replicated at the last possible point at each stage of its journey. In this way, network traffic is minimized.

Additional information — Distribution lists are not supported under WebSphere MQ for z/OS.





Uempty


Notes:

This unit offered a brief look at some of the fields in the message descriptor and how they relate to the IBM WebSphere MQ environment. It also described a method of sending the same data to multiple destinations using a distribution list.


Unit summary

Having completed this unit, you should be able to:• Describe some of the fields in the message descriptor and how they

relate to the message queue environment• Explain the various orders in which messages can be retrieved from a

queue• Describe message groups and segmentation and why they are used• Describe distribution lists



Instructor Guide

Instructor notes:

Purpose — Provide a review of the MQMD.

Details —






Uempty


Notes:

1. Messages are recovered when a queue manager is restarted if they are:

a. Saved by the operator.b. Persistent.c. High-priority messages.d. Retrieved using Msgld and Correlld.

2. Select all that apply. A message group is made up of:

a. One or more physical messages.b. One or more logical messages.c. Only one logical message but several physical messages.d. All of the above.



1. Messages are recovered when a queue manager is restarted if theyare:a. Saved by the operator.b. Persistent.c. High-priority messages.d. Retrieved using Msgld and Correlld.

2. A message group is made up of (select all that apply):a. One or more physical messages.b. One or more logical messages.c. Only one logical message but several physical messages.d. All of the above.



Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty


Notes:

1. Messages are recovered when a queue manager is restarted if they are:

a. Saved by the operator.b. Persistent.c. High-priority messages.d. Retrieved using Msgld and Correlld.

Answer: b.

2. Select all that apply. A message group is made up of:

a. One or more physical messages.b. One or more logical messages.c. Only one logical message but several physical messages.d. All of the above.

Answer: a, b.


Checkpoint answers

1. Messages are recovered when a queue manager is restarted if theyare:a. Saved by the operator.b. Persistent.c. High-priority messages.d. Retrieved using Msgld and Correlld.

Answer: b.

2. A message group is made up of (select all that apply):a. One or more physical messages.b. One or more logical messages.c. Only one logical message but several physical messages.d. All of the above.

Answer: a, b.



Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty
Unit 4. Intercommunication
Estimated time

00:30


This unit describes the function of interconnected systems using IBM WebSphere MQ.



• Describe message channels and message channel agents

• Explain the function of a transmission queue

• Define how a channel is triggered

• Describe queue manager clusters



References



© Copyright IBM Corp. 2011 Unit 4. Intercommunication 4-1

Instructor Guide


Notes:


Unit objectives

After completing this unit, you should be able to:• Describe message channels and message channel agents• Explain the function of a transmission queue• Define how a channel is triggered• Describe queue manager clusters




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 4-2. The message channel WM101 / VM1011.0

Notes:

The figure is a review of the structure of a simple network connection.

An application issues an MQPUT call. As a result, a message is placed on the transmission queue. A message channel agent (MCA) is started, which reads the message from the queue, and sends it to a partner MCA. The partner MCA places the message on the destination queue. At some point, the target application issues an MQGET call and reads the message from the queue.

Sending a message requires:

• A delivery mechanism across the link • A connection mechanism between the systems • A protocol between the sending MCA and the receiving MCA

The physical link can be anything the system supports such as token ring, and ATM. The connection mechanism can be SNA LU6.2, TCP/IP NetBIOS, DECnet, or SPX. Not all of these connection mechanisms are supported on all platforms. The WebSphere MQ


The message channel

MCA

Transmissionqueue

MCA

Destinationqueue

Channel

Physical link

Application 1

MQPUT

Application 2

MQGET

Queue manager QM1

Queue manager QM2




Uempty
Intercommunications manual discusses the networking setup requirements of various WebSphere MQ environments.
The message channel protocol between the message channel agents is the common thread that allows the MCAs on the various platforms to communicate.

A transmission queue is an ordinary local queue with the Usage attribute set to MQUS_TRANSMISSION instead of MQUS_NORMAL.

Only a queue manager (not an application) should put a message directly on a transmission queue, and only an MCA should get a message from a transmission queue. The reason for this process is that a message on a transmission queue must have a special header called the transmission queue header. The queue manager provides the header when it puts the message on the transmission queue. The header also accompanies the message when it is sent across a message channel. The receiving MCA removes the header before putting the message on the destination queue. Normally, an application program does not need to be aware of this header.

To reach a destination queue on a remote queue manager, the local queue manager needs to know which transmission queue to put the message on. Each queue manager contains common software known as the moving service component, which allows a queue manager to communicate with other queue managers.



Instructor Guide

Instructor notes:

Purpose — Take a moment to walk them through the process of putting a message.

Details — Point out that the WebSphere MQ channel message flow is unidirectional. If two-way message flow is wanted, at least two channels need to be defined. You look at the various MCA types in a moment.

It is important to remind students that the application program that performs an MQPUT call may specify a queue name when it does so. The MQPUT does not know where the ultimate destination queue is. The queue manager handles the actual resolution of the name and delivery of the message.

The figure illustrates the following concepts:

• A (network) connection.

The nature of the connection depends on the network protocol being used. For SNA LU6.2, a connection is a conversation on an LU-LU session, and the two message channel agents are the transaction programs (TPs) participating in the conversation. For TCP/IP, a connection is simply a TCP/IP connection that the message channel agents use.

• A message channel is the means by which messages are transmitted from a transmission queue at one queue manager to a destination queue at an adjacent queue manager. Specifically, a message channel consists of a message channel agent at the sending end, a network connection, and a message channel agent at the receiving end.

• A channel definition.

Each end of a message channel has its own definition.

When an application wants to put a message on a remote queue, how does the queue manager know which transmission queue to use? The most common approach is to provide a transmission queue with the same name as the remote queue manager.

On the transmission queue, the message is accompanied by the transmission queue header, structure MQXQH, which contains:

• The remote queue name.

• The remote queue manager name.

• The message descriptor structure MQMD.

Transition statement — There are various types of message channel agents.




Uempty

Figure 4-3. Types of channels WM101 / VM1011.0

Notes:

There is a pair of MCAs for each message channel: a sending MCA, and a receiving MCA. A sending MCA is one that sends messages over a network connection to a receiving MCA at the other end.

When defining a channel at one end of the channel, a sending MCA may be defined as a SENDER or a SERVER, and a receiving MCA as a RECEIVER or a REQUESTER.

The last set of channels listed serves a specific purpose. These channels support the connection between a WebSphere MQ server (SVRCONN) and the WebSphere MQ client (CLNTCONN).

In the figure, an arrow with a dotted line indicates a control flow at channel initiation. In particular, the first such arrow for each pair of MCAs represents the control flow that makes initial contact for the channel. The solid line arrows indicate the direction of flow of the messages once the channel has started.

A RECEIVER or a server connection (SVRCONN) cannot start a channel; the other types can do so.


Types of channels

Transmissionqueue Destination

queue

Transmissionqueue

Transmissionqueue

Transmissionqueue

Destinationqueue

Destinationqueue

Destinationqueue

SENDER

SERVER

SENDER

SERVER

RECEIVER

RECEIVER

REQUESTER

REQUESTER

Control flow

Message flow

Key



Instructor Guide

Generally, every channel must be defined at both ends of the channel, and the name of the channel must be the same at both ends.

When a channel is being defined, each end must be allocated a channel type as part of its definition. There are six channel types to choose from:

• Sender • Receiver • Requester • Server • Server connection (SVRCONN) • Client connection (CLNTCONN)

The channel types at both ends of a channel must be compatible with one another, and the graphic depicts the compatible combinations. The compatible combinations of channel types are:

Sender-receiver Sender-receiver is the most frequently used combination.

Requester-server Requester-server can be used when the end of the channel that sends the messages is not able to start the channel. It can be running unattended and unable to issue the appropriate command.

This combination can also be used when the physical network connection between two nodes is not permanent. A notebook computer, which can be connected to a server machine, might be one example. In this case, the most appropriate combination might be one that allows the notebook, when it is connected, to start a channel and then receive messages from the server machine.

Requester-sender (callback) In this combination, the requester starts the channel but the sender closes it immediately. The sender then restarts the channel according to its channel definition. This feature is known as callback. For example, It can provide additional security when the request to start a channel is coming from an untrusted environment.

Server (fully defined) — receiver or requester A fully defined server is one whose channel definition has the attributes needed to start a channel; in particular, the LU name, the TCP host name, or the IP address. This combination is essentially the same as the sender-receiver combination in terms of function.

Client connection - server connection (not shown the figure) This combination is reserved for use only in the MQI client environment. The client initiates the connection when the MQCONN is issued. Data about the MQI calls flow in both directions. The connection is terminated when the MQDISC is issued.




Uempty
Instructor notes:
Purpose — Introduce the message channel types.

Details — The main criteria for selecting the channel type at each end of a channel are:

• Only a sender, a requester, and a fully defined server are able to start a channel.

• Only a sender and a server are able to get messages from a transmission queue and send them to the other end of the channel.

• Only a requester and a receiver are able to receive messages from the other end of the channel and put them on their respective destination queues.

• An SVRCONN is only started when the MQCONN is issued at the client side. This rule applies only to the MQI client environment, and is not shown on the diagram.

The attributes of the channel definition at one end of a channel depend on the channel type at that end. For example, only those channel types that are able to start a channel need the attributes to be able to perform this task. There are some sample channel definitions later that illustrate this fact.

Transition statement — There are various ways to start channels.



Instructor Guide

Figure 4-4. Starting a channel WM101 / VM1011.0

Notes:

Channels can be started in several ways on most queue managers:

• An operator can start most channels using a command-line command or an interface.

• The transmission queue can be defined as a triggered queue, and the channel can be started when messages arrive that satisfy the triggering conditions.

• Certain channel types can be started remotely from the network.

In the figure, the channel initiator is a special version of a trigger monitor used to start channels. The process used to start channels based on triggering is the same as starting other applications.

Starting and stopping a RECEIVER or an SVRCONN does not start or stop the flow of data; it merely enables or disables the channel to be started from the other side.


Queue manager QM2

Queue manager QM1

Starting a channel

MQPUT…

Sender

Channel initiator

Operator command: START QM1_QM2

Receiver

Queue QM2.Q1(remote queue)

Queue QM2

SYSTEM.CHANNEL.INITQ(initq)

Queue QM2.Q1(local)

Physical link




Uempty
Instructor notes:
Purpose — Describe starting a channel.

Details — With communications between queue managers, it is common practice to trigger the channel when data is placed in its transmission queue. This practice allows channels to be automatically shut down during periods of inactivity, resulting in a more efficient use of system resources.

The client channel is started when the application issues the MQCONN. This process implies that a listener is active on the server and that an SVRCONN has been defined.

There are various ways of starting a channel, including:

• From a command line or panel application • An application program • By a message appearing in a transmission queue which causes a trigger event, which

in turn causes the message channel agent at the sending end to be started • Remotely from the network

Transition statement — Just as a channel can be started in several ways, it can be stopped using various alternatives.



Instructor Guide

Figure 4-5. Stopping a channel WM101 / VM1011.0

Notes:

Usually, channels between queue managers run for long periods. They are started and service a particular transmission queue. However, it is not always best to leave a channel running forever. There is a disconnect value associated with the channel. It allows for normal quiescing of a channel that is active but without work for a specified period.

It is possible to manually stop channels by command as well.

Channels can also stop during error conditions. Because WebSphere MQ provides assured message delivery, messages you want to keep are not lost.


Stopping a channel

Queue manager QM1

MCA

Transmissionqueue

MQGET

MCA

Destinationqueue

Channel

Physical link

MQPUT

Queue manager QM2




Uempty
Instructor notes:
Purpose — Discuss ways channels are stopped.

Details — The ways channels are stopped, and the various states they may be in, are a point requiring much more time than is allocated here. It is covered nicely in the WebSphere MQ Intercommunication manual, and the WebSphere MQ System Administration courses cover them in more detail.

As a start, it is practical to remind students that there is a default disconnect interval associated with channels, and most people use that value to start.

Be careful with issuing a STOP CHANNEL command. It disables triggering of the channel if on the sender side. On the receiver side, it causes the channel to be impossible to start, even if a START CHANNEL is issued from the sender side.

Additional information — If you have a receiver or SVRCONN channel definition, there might be many channel instances using that single definition. The STOP CHANNEL options allow you to target independent instances, and not stop all of the identically named channels. The STOP can be targeted at either the partner machine (CONNAME) or the partner queue manager (QMNAME)

Transitional Statement — Examine remote queues and how they allow application flexibility.



Instructor Guide

Figure 4-6. Remote queues WM101 / VM101q1.0

Notes:

Although it may be transparent to the sending application, the queue manager needs to know where to route messages. When a program wants to send a message to a queue on another system, the application can name the queue and the queue manager to be used. This information allows the sending queue manager to complete the necessary addressing information in the WebSphere MQ transmission queue header (MQXQH). The message is then placed on a transmission queue, either one with the same name as the remote queue manager or, if it is defined, as the default transmission queue of the local queue manager. However, specifying the queue manager name at the application code level is generally not the best solution, except in the case of sending replies.

Usually, a program simply opens a queue without specifying a queue manager. This method is an indication to the local queue manager that the queue named by the application is one that is found among its own definitions (not necessarily a local queue). One of the types of definitions that the queue manager checks is the QREMOTE definition.

If the queue named by the application is a QREMOTE definition, the queue manager can use the information from that definition to complete the addressing information in the


Remote queues

Queue manager QM1

Channel

Physical link

Queue manager QM2

QM2 (transmit queue)

Queue Q2(QREMOTE pointing to

Q3)

Queue Q3

Application 1

MQPUT (Q2)

Application does not need to specify queue manager name to MQPUT, even if not connected to that queue manager




Uempty
MQXQH. The QREMOTE also allows for the specification of a transmission queue to be used. The queue manager can then place the message on a named transmission queue, allowing for greater flexibility. You explore the use of these alternatives as you proceed.
Note

An application may MQPUT to a remote queue, but it cannot issue an MQGET call to a remote queue.

For example, you can send a letter from any mailbox (queue manager). You have to be local to the mailbox (queue manager) to retrieve the letter. However, WebSphere MQ zSeries has the capability for multiple queue managers to share a single local queue from an MQGET perspective.



Instructor Guide

Instructor notes:

Purpose — Describe the QREMOTE definition and its use by the queue manager.

Details — In this example, a program can explicitly open Q3 at QM2 for output. The queue manager uses that information to build the transmission header (MQXQH), and looks for a transmission queue with the same name as the remote queue manager. It is possible there may be a defined queue manager alias that allows that name to be resolved. In addition, if all else fails, the queue manager may have a default transmission queue. If so, any messages that cannot be delivered to a specific transmission queue, based on the definitions and the MQOPEN statement, are placed on that queue.

Additional information — Default transmission queues are useful, but can be troublesome if definitions are not carefully controlled. It is feasible that your payroll information could be sent to a system (and end up on its dead letter queue) that does access to that information. Defaults are not used much.

Transition statement — So far, you have described an environment where a queue manager sends all the information it has across one channel. Review it in detail.




Uempty

Figure 4-7. Message concentration WM101 / VM1011.0

Notes:

Given sufficient capacity, one channel can carry all the messages between a pair of queue managers. This behavior is queue manager-to-queue manager communications. It is less complicated for applications to use the MQI than it is to write code to allow applications to talk directly with each other. This principle is one of the fundamental principles of WebSphere MQ.

The sending queue manager builds transmission headers (MQXQH) for each message to be sent on a particular channel. It includes the destination queue manager name as part of that header. When the destination MCA receives the message, the MQXQH tells it where the message is to go. The MQXQH is stripped from the message before its delivery to the appropriate destination queue. In this scenario, there is no need for multiple paths between the two queue managers.


Message concentration

MCA

Transmissionqueue

MCA

Destinationqueues

Channel

Physical link

App 5App 4 App 6

Queue manager QM1 Queue manager QM2

Q1

Q2

Q3

App 2 App 3App 1



Instructor Guide

Instructor notes:

Purpose — One channel can handle all the traffic between two queue managers.

Details — As an example, all messages for a Sun system can be carried across a single SNA LU6.2 channel from a VSE/ESA system (and vice versa), assuming the definitions for the return channel are set up. The use of one channel to carry all messages is the most common use of channels.


Transition statement — You might choose to use more than one channel to connect queue managers. This technique is called message segregation.




Uempty

Figure 4-8. Message segregation WM101 / VM1011.0

Notes:

When there is a requirement to keep different forms of traffic apart, different queue definitions can point to different transmission queues and thus different channels.

Notice that each channel has its own MCA on each side and its own transmission queue. The figure shows a separate physical link, but it is also possible to use a single physical link for both channels.

In this scenario, the benefit of being able to explicitly name a transmission queue becomes apparent. Messages that need to go on the second channel can be directed there without work from the program.


Message segregation

MCAQM2(transmit queue)

MCAChannel

Physical link

App 5App 4 App 6

Queue manager QM1 Queue manager QM2

MCA MCAChannel

Physical link

QM2.FAST (transmit queue)

Q1

Q2

Q3

App 2 App 3App 1



Instructor Guide

Instructor notes:

Purpose — Message segregation is used for extra capacity, or for special routing needs.

Details — The reasons for wanting to segregate message traffic between two queue managers are:

• To transmit different types of data on different channels — payroll messages and engineering messages, for example. In this case, different destination queues would almost certainly be used.

• To provide a different class of service for some messages.

- Accelerate the delivery of a message by avoiding a heavily used channel. - Delay the transmission of certain messages until an off peak time.

In this case, the different classes of services within similar traffic might still use the same destination queue so that the server application remains unaware of how the messages are arriving. This case is shown in the figure.

• To apply different security controls to different types of messages.

In order to provide message segregation between two queue managers, more than one channel can be defined. Each channel requires a different transmission queue or only one of the channels can be active at a given time.

The attribute XmitQName of the local definition of a remote queue is used to designate a transmission queue other than the one whose name is the same as the remote queue manager.


Transition statement — More than two queue managers can be connected together to form a network through which messages can be routed.




Uempty

Figure 4-9. Multiple hops WM101 / VM1011.0

Notes:

So far, you have been looking at a small portion of a network and considering two queue managers. Using proper definitions, an application can issue MQPUTs that result in messages traveling across intermediate queue managers to reach the final destination queue. In this case, the intermediate queue managers can be looked upon as a gateway. The figure shows application 1 issuing an MQPUT call with a message destined for queue 2 on queue manager 2. The message travels via queue manager 3.

The definitions needed to accomplish this need coordination between the various queue managers, but the application program would not be required to handle the MQPUT any differently.


Multiple hops

MCA

Transmissionqueue

Destinationqueue Q2

MCAMCA MCA

Transmissionqueue

Application 1

MQPUT (Q2)

Queue manager QM1

Queue manager QM3

Queue manager QM2

Application 2

MQGET (Q2)



Instructor Guide

Instructor notes:

Purpose — Routing through a network of queue managers.

Details — A message can be transmitted from one queue manager, through a sequence of intermediate queue managers, to a destination queue manager.

The simplest way of achieving this routing is to define a transmission queue, on each queue manager except the destination one, with the same name as the destination queue manager.

It is worth pointing out that every time you go through a queue manager, you spend cycles and you take time to harden the message to disk. This process is non-trivial, so you should do it only for good reasons:

• Messages are crossing from one enterprise to another and must be verified. See the security topic.

• Messages are being concentrated from a LAN to a WAN, but maybe you need LAN clients and a LAN server.

• You are crossing from a domain full of ASCII queue managers to z/OS and are prepared to dedicate a processor to data conversion.

Additional information — However, in any case routing multiplies channels and MCAs (as well as transmission queues) and presents a challenge to manage them:

• By using a queue manager alias, it is possible to maintain message segregation through a sequence of queue managers.

• In the example depicted on the slide, the queue manager alias resolves to the name of the destination queue manager at the destination queue manager itself.

Transition statement — In some cases, additional functions might be required when MCAs start or when messages are sent and received. These functions can be implemented using exits.




Uempty

Figure 4-10. Channel exits WM101 / VM1011.0

Notes:

At both ends of the channel, exits may be called:

• At initialization time • When a message is read from the transmission queue or placed on the target queue • When a segment is transmitted or received

The security exit is used to establish trust between partners. Commonly, it involves the exchange of encrypted data to ensure that a common encryption technique and key are being used.

The message (or GET/PUT) exit is commonly used to compress and encrypt messages, and to change values in the MQMD.

The segment (or SEND/RECEIVE) exit can also be used for encryption and compression.

The RETRY EXIT makes more than one attempt to MQPUT a message to its destination queue.


Sender

Channel exits

SECURITY EXIT

MESSAGE EXIT

MQGET message

Form segment

SEND EXIT

RECEIVE EXIT

Send segment

Receiver

SECURITY EXIT

AUTODEF EXIT

MQPUT message

SEND EXIT

RECEIVE EXIT

MESSAGE EXIT

Transmit status

Build message

Receive segment

ATTACH

MESSAGE RETRY EXIT



Instructor Guide

Instructor notes:

Purpose — Introduce channel exits and remember to point out the problems associated with securing your channels in this way.

Details —

• The message channel agents between queue managers support the following types of exits:

- Security exit. - Message exit. - Send exit. - Receive exit. - Message-retry exit (not available on z/OS). - Auto-definition exit (version 5 and iSeries queue managers only).

The CLNTCONN and SVRCONN only support security, send, receive, and auto-definition (SVRCONN only).

A message channel agent at either end of a channel can have all types of exits. For some purposes — for example, encryption and decryption — it is necessary that there is a corresponding exit at the other end of the channel.

• Security exits are given control when the channel is initiated after the initial data exchange. They can initiate an exchange of security messages, in a format that is defined by the exits themselves. Transmissions can proceed along the channel only when each exit is satisfied.

A security exit is primarily used for the purposes of authentication.

• A message exit receives control:

- At the sending end, just after a message has been retrieved from the transmission queue, but before it is segmented, if necessary.

- At the receiving end, just before a message is put on the destination queue.

A message exit can modify the fields in the transmission queue header MQXQH, which includes the message descriptor MQMD, as well as the message itself. In particular, it can manipulate the context information of a message.




Uempty
A message exit can be used for any purpose that applies to the message as a whole. It can be used, for example,
- To validate an incoming user identifier. - To substitute a user identifier if the message is entering a new authority domain. - To perform data conversion of the message text. - To change the destination of the message. - To change the reply-to information in the message descriptor. - To process a message using a user-provided template. - For journaling what is transmitted or received on a channel. - To set the user context fields to indicate the degree to which a message can be

trusted. The field ApplOriginData is the most suitable for this purpose.

At the sending or the receiving end, a message exit can cause the message channel agent to place the message on the local dead letter queue. It can also send a report to the reply-to queue if requested in the message descriptor.

• A send exit, at either end, receives control immediately before a segment of data is transmitted over the link. A receive exit, at either end, receives control immediately after a transmitted segment of data has been taken from the link.

Send and receive exits may be called for segments other than those containing application message data; segments containing status data, for example. Neither is called during the initial data exchange or during the operation of the security exits.

Send and receive exits can modify any of the transmitted information; however, send exits must not alter the first 8 bytes of the transmission segment (these bytes are part of the channel protocol header).

Send and receive exits can be used for any purpose that applies to a transmitted segment, such as journaling, encryption and decryption, and data compression.

• The message-retry exit allows suspension of transmission for a moment; then try again to PUT to the destination queue. Where the failure is because a server is running slowly, the queue might have been full when the first MQPUT was issued, but there may be space to satisfy another attempt.

• The auto-definition exit allows you to override the attributes as defined in the SYSTEM.AUTO.RECEIVER or SYSTEM.AUTO.SVRCONN definitions.

• These channel exits require significant customer development and setup efforts. Customers need secure communication, especially with the growth of electronic commerce. You discuss SSL for secure transmission in Unit 6.


Transition statement — When you send data around a network of queue managers, it is possible that the data is represented differently on different platforms; data conversion may be required.



Instructor Guide

Figure 4-11. Application data conversion WM101 / VM1011.0

Notes:

In this example, you see payroll data flowing from a Windows environment to a z/OS environment. This type of flow is an everyday occurrence in many installations. However, data that flows between disparate platforms in a network introduces a special problem: it is not represented in an identical manner everywhere. Whether integer or character, ASCII or EBCDIC, US English or French, data conversion is an issue that must be considered.

WebSphere MQ offers some assistance with data conversion. In general, as long as the data is character, an application can identify it as such in the message descriptor (MQMD), and the receiving queue manager can handle the conversion, if requested. In the case where numeric and character data make up the application data, user-written exits need to be provided. The queue manager invokes the format field identified exit during MQGET processing, if asked to do so.

As a result, if a message is sent in ASCII, it is converted to EBCDIC in this example, and the receiver is able to understand the information.


Application data conversion

Sender Receiver

Payroll application on Microsoft Windows

MQPUT

Queue manager QM1

Remote queuedefinition

Transmissionqueue

Payroll application on IBM z/OS

MQGET

Queue manager QM2

Payrollqueue




Uempty
Instructor notes:
Purpose — Mention data conversion.

Details — Data conversion is a fact of life. Most of the students realize this fact and accept what you say. If someone wants to get into a major discussion, refer them to the WebSphere MQ Application Programming Reference and the WebSphere MQ Intercommunications manuals. This location in the course is not a place to go into this topic in detail. SupportPac MA07 gives an example of an EBCDIC-ASCII data conversion exit, including sample code in C, along with a white paper on data conversion. Refer students to this Support Pack if they want further information about data conversion, or would like to write their own conversion exit.

The mechanics of how to set up the putting and getting programs for data conversion is also covered in the Application Programming Workshop.


Transition statement — It is worth looking at the characteristics these channels have, as they feed into your network design.



Instructor Guide

Figure 4-12. Channel attributes example WM101 / VM1011.0

Notes:

Only a few of the possible attributes are shown in the figure to give a flavor for the types of things that can be controlled in the channel definitions created by an administrator.

• The names on both sides must be identical (including case).

• CHLTYPE is the channel type and is required.

• TRPTYPE is the transport type to be used and must match on both ends.

• CONNAME is the connection name of the partner.

• XMITQ tells the sending MCA what transmission queue to obtain its messages from.

• DISCINT is the time a sending MCA is to wait for a message on the transmission queue before becoming inactive.

• HBINT is used to ensure that both sides of a channel are still active.

• MSGEXIT contains the name of a user-written exit that can be used to interrogate or change contents of a message (including headers).


Channel attributes example

• At sender side:DEFINE CHANNEL(ATLANTA_HURSLEY) CHLTYPE(SDR) +

TRPTYPE(TCP) CONNAME(10.1.23.17) XMITQ(HURSLEY) +

DISCINT(6000) HBINT(300)

• At receiver side:DEFINE CHANNEL(ATLANTA_HURSLEY) CHLTYPE(RCVR) +

MSGEXIT(CHKUSER)




Uempty
The IBM WebSphere MQ Script (MQSC) Command Reference lists all the attributes, and explains which are permitted on the various channel types as well as the various platforms. The use of the various attributes is further discussed in the WebSphere MQ Intercommunication manual.


Instructor Guide

Instructor notes:

Purpose — Briefly introduce some common channel attributes.

Details — The examples shown are valid channel definitions that would work. However, the examples are not a complete discussion of all attributes. It is intended to provide a flavor for the possible types of things that can be included. Do not be tempted to cover these attributes in detail, as the figure is just an example.

As with all definitions, any of the attributes not included are taken from the default definitions. Few are required; the WebSphere MQ Script (MQSC) Command Reference describes the attributes that are.


Transition statement — Next, you look at queue manager clusters.




Uempty

Figure 4-13. Queue manager clusters WM101 / VM1011.0

Notes:

A queue manager cluster is a network of queue managers that are logically associated in some way. The queue managers can be on the same system or across a network, even across enterprises.

Queue managers within the cluster may optionally advertise queues to other queue managers in the cluster. The other queue managers may then put messages to those queues by creating a sender channel dynamically from attributes (such as the network address) that they hold in a repository of cluster information.

With queue manager clusters, a WebSphere MQ administrator does not need to define remote queue definitions and channel definitions between each of the queue managers. In addition, if a queue is defined on more than one queue manager in the cluster, the messages can be routed in the most efficient manner. This functionality enables workload balancing and failover if one queue becomes unavailable.


Cluster

Queue manager clusters

Queue manager QM3

TO.QM1 Queue manager QM2

Queue manager QM1

TO.QM2

TO.QM3



Instructor Guide

Instructor notes:

Purpose — Introduce queue manager clusters.

Details — Emphasize the benefits of clusters:

• Reduced system administration • Increased availability and workload balancing

Additional information — Refer to the WebSphere MQ Queue Managers Clusters manual.

Transition statement — Now, look at cluster workload management.




Uempty

Figure 4-14. Cluster workload management WM101 / VM1011.0

Notes:

IBM WebSphere MQ clusters implement workload distribution by using various queue manager options. This figure shows how two of the options — weighting and priority — can be used. Note how the priority attribute can be used to send all messages to a primary data center, and then redirect to a backup site if the network to the prime location is down. The weighting parameter tells the cluster how to distribute the workload to the queues within the priority. In this example, two messages are routed to QM1 for every one message routed to QM2.

This example is a simplified example. There are a number of other factors that are used to determine message distribution. The WebSphere MQ Queue Managers Clusters manual describes the complete algorithm that is used for cluster workload management.


Site2

Site1

Cluster workload management

QM0

ClusQ

QM1

ClusQ

QM2

ClusQ

QM3

ClusQ

QM4

ClusQ

PRI=2WT=2

PRI=2WT=1

PRI=1WT=2

PRI=1WT=1



Instructor Guide

Instructor notes:

Purpose — Introduce queue manager clusters workload management.

Details — Again, emphasize the benefits of clusters:

• Automatic failover • Increased availability and workload balancing

Additional information — Refer to the WebSphere MQ Queue Managers Clusters manual.

Transition statement — In a z/OS Sysplex environment, you can create shared queues across the Sysplex.




Uempty

Figure 4-15. Shared queues Sysplex support WM101 / VM1011.0

Notes:

Shared queues help to balance workload and provide redundancy in case of queue manager failure.

Assume that MVSA and MVSB are cloned z/OS images running identical applications.

• With SQ1 being a shared queue, the application does not depend on the availability of a specific queue manager; any queue manager in the Sysplex can service the queue.

• If the queue manager on MVSA fails, the application and queue manager on MVSB can still GET the messages on SQ1, irrespective of whether these were originally PUT by the mover on MVSA or MVSB.

Furthermore, either mover can send the reply messages back to the remote queue manager.

• Natural workload balancing: If the application on each MVS image is processing a message that was retrieved from shared queue SQ1, the MVS image that finishes first will MQGET the next message from SQ1. Thus, the least-busy MVS image processes the most messages.


z/OS Sysplex

Shared queues Sysplex support

WebSphere MQ on AIX

DB2 shared data

WebSphere MQshared data

SQ1

Coupling facility

MVSA

Application

DB2A

TABA

MQA

LQ1

MOVER

WebSphere MQ on Windows

MVSB

Application

DB2B

TABA

MQB

LQ1

MOVER



Instructor Guide

• You can add extra queue managers in extra MVS images to increase the processing power against a shared queue, up to the coupling facility capacity. This configuration is especially useful for applications that do significant non-WebSphere MQ work.

• Intergroup communication allows messages to be delivered via the coupling facility for even faster throughput.




Uempty
Instructor notes:
Purpose — Show the overall use and benefit of shared queues.

Details — Will be provided by the following slides.

Additional information — You have not yet introduced the term queue-sharing group and its concept, so do not use this expression. The first bullet text (in the student notes on the previous page) should correctly read “queue manager in the queue-sharing group”, not “queue managers in the Sysplex”. However, the change in text was done deliberately.

Transition statement — Clients have been mentioned a few times, but take one more look so that you clearly understand the differences.



Instructor Guide

Figure 4-16. MQI client channels WM101 / VM1011.0

Notes:

WebSphere MQ clients use special channels to enable connections to the server. Many clients may connect using a single server. It is possible that one SVRCONN may support several clients. It is also possible for a client to connect to various servers.

In this picture, you see that the clients are using standard WebSphere MQ calls. However, the queue manager to which the calls are directed is on the server. When the MQCONN call is issued, the actual connection is activated. When the calls are issued, the client stub is responsible for sending the calls to the server and returning to the applications any messages coming from the server.

Although channel definitions are used, these MQI channels are different from queue manager-to-queue manager channels. There are no transmission queues, so any assured delivery based on the MCA doing unit-of-work processing is not included. Applications therefore cannot rely on assured message delivery being provided by the MCA.

The connection data flow is bidirectional. One set of definitions enables two-way communication. In fact, it is possible to have just an SVRCONN definition and to use environment variables for the client connection information.


MQI client channels

QM1 (server)

Linux

Windows

HP-UX

MQCONN....

MQDISC

ClientsCLNT.CONN

SVRCONN

MQCONN....

MQDISC

MQCONN....

MQDISC




Uempty
Instructor notes:
Purpose — Provide a final review of clients.

Details — Many times, clients look attractive because they are a cheap solution. However, implementation of MQI clients should be carefully thought out. Sometimes, clients look like a great way to use IBM WebSphere MQ without spending a lot; the trade-off is that the client may not be as robust as a full WebSphere MQ queue manager.


Transition statement — The unit summary is next.



Instructor Guide


Notes:

The method of communicating between queue managers described in this unit is one of the fundamental strengths of WebSphere MQ. Allowing for connectionless communications where the queue managers and message channel agents handle the delivery of messages across the network reduces the need for day-to-day administration. In some cases, it also alleviates special programming requirements.


Unit summary

Having completed this unit, you should be able to:• Describe message channels and message channel agents• Explain the function of a transmission queue• Define how a channel is triggered• Describe queue manager clusters




Uempty
Instructor notes:
Purpose — Review the idea of Intercommunication in WebSphere MQ.

Details — IBM WebSphere MQ channels can be confusing when they are first encountered. Sometimes, it is useful at the end of this unit to draw a picture of two queue managers that are connected and to actually do an exercise of defining the needed parts. However, that is beyond the scope of the class and depends on the level of skill of the class overall.




Instructor Guide


Notes:

1. Which of the following is not required for remote queuing between two queue managers?

a. A delivery mechanism across a link.b. A protocol between two message channel agents.c. A remote queue definition.d. A transmission queue.

2. True or False: WebSphere MQ message channel agents must always come in pairs.

3. True or False: The following command is a valid definition for a transmission queue: DEFINE QLOCAL(XMITQ1) MAXDEPTH(1000)

4. Which of the following are valid channel types (message channel agents) that can send data held in a transmission queue?

a. Sender.b. Receiver.c. Requester.



1. Which of the following is not required for remote queuing between two queue managers?a. A delivery mechanism across a link.b. A protocol between two message channel agents.c. A remote queue definition.d. A transmission queue.



4. Which of the following are valid channel types (message channel agents) that can send data held in a transmission queue? a. Sender.b. Receiver.c. Requester.d. Server.




Uempty
d. Server1.


Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty


Notes:


a. A delivery mechanism across a link.b. A protocol between two message channel agents.c. A remote queue definition.d. A transmission queue.

Answer: c. Although a remote queue definition can be used, it is not required.


Answer: True.


Answer: False. The DEFINE command must include a USAGE clause that defines the queue as a transmission queue: DEFINE QLOCAL(XMITQ1) MAXDEPTH(1000) USAGE(XMITQ)




a. A delivery mechanism across a link.b. A protocol between two message channel agents.c. A remote queue definition.d. A transmission queue.Answer: c. Although a remote queue definition can be used, it is not required.


Answer: True.3. True or False: The following command is a valid definition for a transmission

queue:DEFINE QLOCAL(XMITQ1) MAXDEPTH(1000)

Answer: False. The DEFINE command must include a USAGE clause that defines the queue as a transmission queue:DEFINE QLOCAL(XMITQ1) MAXDEPTH(1000) USAGE(XMITQ)



Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty


Notes:


a. Sender.b. Receiver.c. Requester.d. Server1.

Answer: a and d. The requester can start the channel but does not send data held in a transmission queue.




a. Sender.b. Receiver.c. Requester.d. Server.

Answer: a, d. The requester can start the channel but does not send data held in a transmission queue.



Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty
Unit 5. System administration
Estimated time

00:30


This unit describes the administration of IBM WebSphere MQ and its queue managers.



• List the system administration interfaces for WebSphere MQ

• Describe the tasks for which a WebSphere MQ administrator is responsible

• Explain the concepts of logging and recovery

• Describe some of the common administrative features of WebSphere MQ



References



© Copyright IBM Corp. 2011 Unit 5. System administration 5-1

Instructor Guide


Notes:

After a brief look at the system management associated with IBM WebSphere MQ, you should realize that familiarity with a particular operating system makes working with IBM WebSphere MQ on that system a straightforward task.

IBM WebSphere MQ, in general, takes advantage of the facilities available in the operating system to accomplish its system management tasks.


Unit objectives

After completing this unit, you should be able to:• List the system administration interfaces for WebSphere MQ• Describe the tasks for which a WebSphere MQ administrator is

responsible• Explain the concepts of logging and recovery• Describe some of the common administrative features of WebSphere

MQ




Uempty
Instructor notes:
Purpose — Review objectives for unit on system management.

Details — System administration cannot be taught in a brief lecture. Encourage students to attend one of the WebSphere MQ system administration courses.

Transition statement — Consider what all these platforms have in common.



Instructor Guide

Figure 5-2. Introduction WM101 / VM1011.0

Notes:

There are family resemblances in the platforms built on each of the different code bases. Much of what is known about administering WebSphere MQ can be applied to all platforms. Some of the unique properties of the various code bases are:

• IBM WebSphere MQ for z/OS has its own code base, with several administrative interfaces.

• Queue managers for the other WebSphere MQ implementations are all managed using the same set of WebSphere MQ commands. Additionally, WebSphere MQ for Windows and for Linux have an Eclipse-based GUI which can be used to administer any queue managers on any WebSphere MQ platform. iSeries has, in addition, a set of commands that map to the WebSphere MQ commands.

• All implementations support PCF (programmable command format) messages, which facilitate programmed administration.

• IBM WebSphere MQ for Windows, AIX, iSeries, Linus, HP-UX, and Solaris support the WebSphere MQ Administration Interface (MQAI).


Introduction

IBM WebSphere MQ for z/Series

IBM WebSphere MQ for iSeries, UNIX,

Linux, and Windows

(Distributed WebSphere MQ)




Uempty
Instructor notes:
Purpose — Provide interface descriptions.

Details — The intent is to acquaint the students with the concept that once IBM WebSphere MQ is learned on one platform, much of the knowledge can be used on other platforms.

Additional information — WebSphere MQ for z/OS supports the use of PCF messages on its SYSTEM.COMMAND.INPUT queue.

Transition statement — Examine some of the tasks a WebSphere MQ administrator has to perform, beginning with product installation.



Instructor Guide

Figure 5-3. Installation WM101 / VM1011.0

Notes:

Installation on WebSphere MQ uses the same mechanism that is used for installing most other software on the particular platform. There is no major learning curve required to be able to work on a platform that you already know.

As with most software products, it is highly recommended that you apply any recommended maintenance as one of your installation steps.


Installation

RESTORE

SYSADM

SWINSTALL

Add/RemoveProgramsVMSINSTALLGO

LICPGM

SMIT

Software Installer/2

PKGADD

SMP/E




Uempty
Instructor notes:
Purpose — Reassure them about the installation process.

Details — Software for most of the platforms is available on CD-ROM. Some can also be obtained on tape, cartridge, or diskettes. Some examples as shown in the chart:

• IBM WebSphere MQ for iSeries uses GO LICPGM

• IBM WebSphere MQ for Windows uses setup.exe (Add/Remove programs).

• IBM WebSphere MQ for Oracle Solaris uses pkgadd.

• IBM WebSphere MQ for AIX uses installm.

• IBM WebSphere MQ for HP-UX uses swinstall.

• IBM WebSphere MQ for z/OS uses SMP/E.

Transition statement — Installation is really the easy part; the ongoing administration is more involved.



Instructor Guide

Figure 5-4. Administrative tasks WM101 / VM1011.0

Notes:

The figure lists the common administration tasks. Administrative tasks can be divided into two sections. The first two items refer to the initial installation and setup, which is required only once. The remaining tasks are day-to-day operations that require a knowledgeable WebSphere MQ administrator. Many of the tasks listed would be done working with other groups: for instance, managing channels would require planning with the networking team; managing security would require planning with the security group.


Administrative tasks

• Install the IBM WebSphere MQ base code• Create queue managers• Operate the queue manager• Manage

– Queue manager objects– Logging and recovery including space requirements– Adapters– Channels– Performance– Security– Problem detection and resolution




Uempty
Instructor notes:
Purpose — Provide details on the tasks you need to do to get a queue manager up and running, and to maintain it.

Details — Administrative tasks for WebSphere MQ are similar to administrative tasks for other software applications.

Additional information — This figure is an overview; do not spend too much time on it.

Transition statement — You need to look at how you perform these tasks for individual systems. First, you look at the interfaces available on z/OS.



Instructor Guide

Figure 5-5. WebSphere MQ administrative interfaces WM101 / VM1011.0

Notes:

The figure depicts the administrative interfaces for WebSphere MQ.

It is possible to manage WebSphere MQ for a given system in several different ways, as you can see from the figure. A choice of interfaces offers great flexibility to the administrator. Notice that the commands are placed on a queue, and replies also use a queue. WebSphere MQ uses its own facilities to do much of its work.

Messages containing WebSphere MQ commands can be put on the system command input queue and processed by the command server. Such messages can even originate on other systems. By sending control commands or programmable command format messages to another queue manager's command server, an administrator on the first system can look at or change queue manager objects on the second system.

The queues on the right side of the figure show instrumentation as input. Instrumentation refers to events that can occur in the WebSphere MQ environment. One common type of event is starting or stopping a channel (a message is placed on the SYSTEM.ADMIN.CHANNEL.EVENT queue).


WebSphere MQ administrative interfacesSystem administration

application

TSO, ISPF, andWebSphere MQ

Explorer

Queuemanager

Batch style utilityCSQUTIL, RUNMQSC,

STRMQMMQSC

WebSphere MQAdministration

Interface (MQAI)

Queues Processes Namelists Channels Instrumentation

CommandServer and processor

Initializationdata sets

MVS console andCL commands

Customer and vendoradministration

application




Uempty
Other platforms can have additional events unique to them, such as:
• When a namelist is created on a z/OS queue manager, an event message is placed on the z/OS SYSTEM.ADMIN.CONFIG.EVENT queue.

• When a logging event occurs on a distributed queue manager, a message is placed SYSTEM.ADMIN.LOGGER.EVENT queue.

The use of event information (and even the removal of messages from these queues) is left to you. WebSphere MQ does not provide programs to process these event messages.



Instructor Guide

Instructor notes:

Purpose — Introduce the administration interfaces for IBM WebSphere MQ for z/OS.

Details — The WebSphere MQ commands

• The commands available for IBM WebSphere MQ for z/OS administration are a subset of the WebSphere MQ, or MQSC commands, as defined in the WebSphere MQ Script (MQSC) Command Reference.

• A WebSphere MQ command is just text, and so a normal text editor can be used to prepare a data set containing a sequence of these commands. The reply to a WebSphere MQ command is also just text.

The system command input queue

• A message containing a WebSphere MQ command can be placed on the SYSTEM.COMMAND.INPUT queue in order for it to be processed by the command server or processor. The reply is sent to the specified reply-to queue.

• The system command input queue allows the queue manager to be administered remotely, provided the message data containing a command or a reply can be converted into EBCDIC if necessary.

• The system command input queue is used by:

- The batch utility, CSQUTIL.

- A customer or vendor-written administration application.

Queue manager objects

• Although channels for distributed queuing without CICS ISC appear alongside the queue manager, queues, processes, and namelists in the diagram, channels are not queue manager objects. A channel cannot be opened by MQOPEN, nor can its attributes be queried by MQINQ.

The system administration application

• The supplied system administration application can be used to administer a local or a remote WebSphere MQ. Information entered on the panels or explorer is used to generate the appropriate commands, which are placed on the system command input queue by the application.

WebSphere MQ commands cannot be entered directly from the panels of the application.

Other places where commands can be entered

• Entering a command on the z/OS console or its equivalent (by entering command mode from within TSO, or from within SDSF, for example), uses a private interface to the command server or processor.

• Commands in the initialization input data sets CSQINP1 and CSQINP2 are also processed with a private interface to the command server or processor.




Uempty
• The WebSphere MQ for z/OS System Administration Guide explains all of the ways to enter commands.
Instrumentation events

An instrumentation event is a predefined set of conditions that can occur during the operation of a queue manager. There are four categories of instrumentation events. Configuration events apply only to IBM WebSphere MQ for z/OS.

• A queue manager event

Events in this category are related to the definitions of queue manager resources. An example of a queue manager event is when an application attempts to open an object that does not exist.

• A performance event

An event in this category occurs when a predefined threshold has been reached by a resource. For example:

- The depth of a queue has reached a predefined value, such as 80% full.

- A queue is full.

- Following a get from a non-empty queue or a put, a queue is not serviced by a get within a predefined interval of time.

• A channel event

There are only two channel events: when a channel starts, and when a channel stops.

• A configuration event

Events in this category are notifications about the attributes of an object. They are generated automatically when an object is created, changed, or deleted, and are also generated by explicit requests; for example, when a namelist is created.

Instrumentation events are enabled and disabled by setting the appropriate values for queue and queue manager attributes using WebSphere MQ commands. These attributes cannot be set using MQSET, nor can they be queried using MQINQ. Channel events do not require enabling. They occur automatically and cannot be disabled (unless you delete the SYSTEM.ADMIN.CHANNEL.EVENT queue).

When a queue manager event occurs, the queue manager creates an event message and puts it on the queue manager event queue. Similarly, when a performance event occurs, the queue manager puts an event message on the performance event queue. However, when a channel event occurs, it is the channel that puts the event message on the channel event queue. If the queue manager at both ends of channel supports instrumentation events, a channel event message is put on the channel event queue at both queue managers.

An event message is in programmable command format (PCF). Each event message specifies:

• The category of the event



Instructor Guide

• A reason code indicating the cause of the event

• Other information specific to the event

Using the system command input queue, a system management utility can enable selected instrumentation events, and then monitor the event queues by waiting for event messages. When an event message is retrieved, the utility can determine the source of the problem, and either inform the administrator or instigate the appropriate action itself. An event queue may be local or remote, so that monitoring activities can be centralized.

The CICS adapter application

• The CICS adapter panel application provides function to operate the CICS adapter.

Additional information — The structure, event queues, command server, and other components are common (more or less) across all the queue managers. The supplied WebSphere MQ Explorer is an Eclipse-based administration tool. In addition, SupportPac IS02 provides a common administrative environment for both IBM WebSphere MQ and IBM WebSphere Message Broker.

Transition statement — WebSphere MQ Explorer is a primary means of performing administrative tasks.




Uempty

Figure 5-6. WebSphere MQ Explorer WM101 / VM1011.0

Notes:

See the IBM WebSphere MQ website for operating system platforms and versions.


WebSphere MQ Explorer

• Runs on Windows XP and Linux platforms• Integrated with Eclipse • Many usability features, such as advanced filtering and a “compare”

function to identify differences between WebSphere MQ objects• Merges WebSphere MQ services into WebSphere MQ Explorer• Can remotely administer queue managers on all platforms, including

z/OS



Instructor Guide

Instructor notes:

Purpose — Outline the prerequisites of IBM WebSphere MQ V7.1

Details — Outline what software is needed for WebSphere MQ.


Transition statement — The next figure shows a WebSphere MQ Explorer window.




Uempty

Figure 5-7. WebSphere MQ Explorer: Queue Manager view WM101 / VM1011.0

Notes:

When a queue manager is selected in the Navigator view, the Content view displays three tables showing the status and properties of the queue manager.


WebSphere MQ Explorer: Queue Manager view



Instructor Guide

Instructor notes:

Purpose — Exhibit queue manager window.

Details —






Uempty

Figure 5-8. WebSphere MQ Explorer: Queues view WM101 / VM1011.0

Notes:

When the Queues folder is selected (or the other object folders under a queue manager), the Content view shows one table listing the queue objects.


WebSphere MQ Explorer: Queues view



Instructor Guide

Instructor notes:

Purpose — Exhibit queue management window.

Details —


Transition statement — The next slide shows a Queue status window.




Uempty

Figure 5-9. WebSphere MQ Explorer: Queue selected WM101 / VM1011.0

Notes:

A context item on a queue in the table launches a dialog showing the status of that queue.

Status dialogs can also be shown for other objects:

• Queue manager

• Channel

• Service

• Listener

• Coupling facility


WebSphere MQ Explorer: Queue selected



Instructor Guide

Instructor notes:

Purpose — Exhibit the queue status window.

Details —


Transition statement — The next slide shows an Eclipse queue compare window.




Uempty

Figure 5-10. WebSphere MQ Explorer: Compare WM101 / VM1011.0

Notes:

Another menu item on a queue in the table launches a dialog allowing the properties of the queue to be compared to those of another queue. The queues being compared can be on the same or a different queue manager, even z/OS queues.

“Compare with” is available for most objects in WebSphere MQ Explorer.


WebSphere MQ Explorer: Compare



Instructor Guide

Instructor notes:

Purpose — Exhibit the compare queue window.

Details —


Transition statement — The next slide illustrates Queue display filter.




Uempty

Figure 5-11. WebSphere MQ Explorer: Filtering WM101 / VM1011.0

Notes:

The number of queues shown in the table can be reduced by using a programmable command format filter to select only those queues matching specified characteristics.

• The filtering is done at the remote queue manager to reduce network traffic.

• Explorer allows named filters to be created and persisted for each object type.

• Explorer also ships with a number of predefined filters.


WebSphere MQ Explorer: Filtering



Instructor Guide

Instructor notes:

Purpose — Exhibit the queue display filter functionality.

Details — The graphic depicts a filter which only displays queues which have a queue depth greater than zero.


Transition statement — The next slide shows the outcome of filtering.




Uempty

Figure 5-12. WebSphere MQ Explorer: Filter results WM101 / VM1011.0

Notes:

Filtering allows the inclusion or exclusion of queue information. The sample filter was created to bypass the viewing of queues with a depth equal to zero.


WebSphere MQ Explorer: Filter results



Instructor Guide

Instructor notes:

Purpose — Exhibit the filter display.

Details — Only queues with a queue depth greater than zero display in the queue list processor.


Transition statement — Next, you discover specific considerations for IBM WebSphere MQ on z/OS.




Uempty

Figure 5-13. Queue storage management on z/OS WM101 / VM1011.0

Notes:

z/OS is a virtual storage operating system. It endeavors to keep the queues available in storage as far as possible, and uses lazy write to disk (asynchronously). The hardening function relies on the log.

You need to define buffer pools for the queues and align them with VSAM page data sets to which the messages are eventually put. You also need to back up the data sets regularly.

This hierarchy of queues to storage classes to page data sets to buffer pools is unique to WebSphere MQ for z/OS system. So, some early planning regarding utilization of these resources is necessary.


Queue storage management on z/OS

• Normally, four buffer pools in memory (maximum of 16)– By default, 1000 buffers of 4 KB each

• 100 page data sets– VSAM linear data sets– 4-KB pages– Up to 64 GB in size

• Storage classes– Associates local queue with page set

• Created by commands or utilities• Objects stored in page set 00• Back up page sets regularly



Instructor Guide

Instructor notes:

Purpose — Describe the components of queue storage management.

Details —

• IBM WebSphere MQ for z/OS stores messages and object definitions as pages of information:

- In areas of virtual memory called buffer pools. - In specially formatted VSAM linear data sets called page sets.

• A buffer in a buffer pool holds one page of information. A record in a page set also holds one page of information. A page = 4 KB.

• IBM WebSphere MQ for z/OS is designed to keep pages in the buffer pools as long as possible in order to obtain the best performance. However, as a buffer pool starts to fill, updated pages are written out to the page sets to free up space in the buffer pool. This process is generally done asynchronously (known informally as a “lazy-write”).

• A buffer pool is defined to the queue manager with the WebSphere MQ command, DEFINE BUFFPOOL. The same command is used to define the number of buffers in the buffer pool. You can define up to four buffer pools.

• You can have up to 100 page sets. A page set is associated with a physical data set through the DDNAME in the WebSphere MQ for z/OS started task procedure.

• Each page set is associated with a buffer pool with the WebSphere MQ command, DEFINE PSID. Pages belonging to a page set may only occupy buffers in the associated buffer pool.

• A local queue has an attribute called StorageClass. This attribute is used to map a local queue to a page set with the WebSphere MQ command, DEFINE STGCLASS. This means that messages belonging to the local queue occupy pages belonging to that page set. More than one local queue may map to the same page set.

• IBM WebSphere MQ for z/OS, holds the definitions of all objects, including channel definitions in page set 00.

• From the point of view of system management, backup copies of the page sets should be made at regular intervals. This speeds up the process of forward recovery from the log if a page set becomes corrupted.

Transition statement — IBM WebSphere MQ for z/OS supports the ability to have shared queues with more than one IBM WebSphere MQ for z/OS queue manager.




Uempty

Figure 5-14. Queue sharing on z/OS WM101 / VM1011.0

Notes:

WebSphere MQ for z/OS can share queues between queue managers. Sharing queues provides high availability of messages to any queue manager that can process the message.

Sharing queues requires:

• A series of structures to be defined for the coupling facility

• A DB2 shared repository to be established to contain the definitions of the shared queues and messages greater than 63 KB in size


Queue sharing on z/OS

DB2 databaseShared repository

Local logs Local pagesets

Local logs Local pagesets

Coupling facility

QM1 QM2



Instructor Guide

Instructor notes:

Purpose — Introduce the shared queue concept.

Details — Do not get into any details beyond the need to set up DB2 and the coupling facility.

Additional information — Many of the setup steps may be done by others in the z/OS support area; that is, coupling facility list structure definition and sizing. The WebSphere MQ for z/OS Concepts and Planning Guide contains a good overview of the requirements.

Transition statement — Next, you look at the log and bootstrap data sets for the z/OS environment.




Uempty

Figure 5-15. Log and bootstrap data sets on z/OS WM101 / VM1011.0

Notes:

The log is a high-performance file accessed sequentially in journal mode to contain persistent messages and other updates that must survive failure. The log can include media images of resources that need to be recovered after DASD failures.

The bootstrap data set records the status of the log, including the presence of media images, checkpoint records, and the oldest unused message in the queues.

In a production environment, use dual logs and dual bootstrap data sets.


Log and bootstrap data sets on z/OS

Bootstrap data sets

Inventory and status

Offload

Log input buffers

Log output buffers

Activelogs

Archivelogs



Instructor Guide

Instructor notes:

Purpose — Describe the log and bootstrap data sets.

Details — IBM WebSphere MQ for z/OS records all persistent messages, changes to object definitions, and other significant events in the active log as they occur. Non-persistent messages are held in a separate log.

Each active log data set is a VSAM linear data set with a control interval size of 4 KB. Each control interval contains one VSAM record.

Log records are placed sequentially in the log output buffers, which are formatted as VSAM control intervals. The contents of the log output buffers are written to an active log data set when:

• The buffers become full.

• The write threshold is reached (a specified number of log output buffers have been filled, as determined by the WRTHRSH parameter in CSQ6LOGP).

• A commit takes place.

WebSphere MQ for z/OS takes a checkpoint:

• When a predefined number of log records has been written (this number is determined by the LOGLOAD parameter in CSQ6SYSP).

• At the end of a successful restart.

• At normal termination.

No updated page in a buffer pool survives more than three checkpoints before it is written to the page set. In this way, when recovering following a system failure, IBM WebSphere MQ for z/OS does not need to go too far back in the log in order to reinstate the page as it was before the failure.

At a normal termination checkpoint, all updated pages are written to their page sets.

• The active log data sets form a ring. When WebSphere MQ for z/OS fills one, it moves on to the next.

• Dual active logging is supported, in which case there would be two rings of active log data sets. When an active log data set becomes full, its contents are automatically, and asynchronously, offloaded to an archive log data set on DASD or on magnetic tape. After offload, an active log data set is ready for reuse when its turn comes.

• The bootstrap data set (BSDS) is required by WebSphere MQ for z/OS. It is used to maintain an inventory of the active and archive log data sets and their status.

• Dual archive logging is supported. Each time a new archive log data set is created, a copy of the BSDS is also created for archive purposes.

• WebSphere MQ for z/OS also maintains a soft log in virtual memory for non-persistent messages.




Uempty
Transition statement — Now you look at how journaling and recovery are implemented for iSeries.


Instructor Guide

Figure 5-16. Journaling and recovery (iSeries) WM101 / VM1011.0

Notes:

WebSphere MQ for iSeries uses OS/400 journaling support to help its backup and recovery strategy.

WebSphere MQ for iSeries holds its data in an individual library for each queue manager, and in stream files in the integrated file system (IFS).

The queue manager-specific libraries contain journals, journal receivers, and objects required to control the work management of a queue manager.

The IFS directories contain WebSphere MQ configuration files, the descriptions of WebSphere MQ objects, and the data they contain.

For message queues, all persistent messages are recorded in the journals, while non-persistent messages are not.


Journaling and recovery (iSeries)




Uempty
Instructor notes:
Purpose — To introduce queue storage management, journaling, and recovery on OS/400.

Details — The persistent messages in a queue, and the queue definition, are stored in the integrated file system (IFS). From the point of a program, the IFS is a contiguous piece of single-level, shared memory provided by OS/400. In general, OS/400 decides where each piece of data in the IFS actually resides, in main memory or disk.

Non-persistent messages in a queue are stored by preference in a different stream file. The stream file is allocated dynamically when the queue is first opened in a queue manager session, and is discarded at the end of the session. If the queue directory under the IFS structure of your queue manager becomes full, the non-persistent messages are then spilled over into the directory containing the persistent messages.

Each process definition is also stored in its own directory under the hierarchical file system of your queue manager.

WebSphere MQ for iSeries uses the OS/400 journaling facility to maintain a lot for recovery purposes. WebSphere MQ for iSeries records all persistent messages, changes to object definitions, and other significant events in the journal AMQAJRN as they occur.

A journal has associated journal receivers that contain the actual information being recorded. A journal receiver is an OS/400 object to which updates can only be appended, and so it fills up eventually. Like the directories in the IFS, it is a single-level memory from the point of view of the program, and OS/400 generally decides where each piece of data in a journal receiver actually resides.

At any one time, only one journal receiver is attached to a journal. When the size of the currently attached journal receiver passes a threshold of 65536 KB, WebSphere MQ for iSeries issues a request to OS/400 for it to be detached and replaced by a new journal receiver.

OS/400 objects reside in one library per queue manager, and all queue data and shared memory are present in the integrated file system (IFS).

The data in this directory is retained when the product is deleted.

Many events cause WebSphere MQ for iSeries to force the journal to be used. This action is only performed when IBM WebSphere MQ for iSeries writes an entry in the journal. Persistent updates to message queues happen on two stages. The records representing the update are first written to the journal; then the queue file is updated. The journal receivers can therefore become more up-to-date than queue files.

The events that cause WebSphere MQ for iSeries to force the journals are:

• A sync point event (a commit or a rollback)

• A get or a put of a persistent message, whether within, or outside of, sync point control

• A change to a queue definition



Instructor Guide

• A checkpoint

Checkpoints are generated automatically by WebSphere MQ. The checkpoint consists of the series of journal records needed to restart the queue manager. Checkpoints are taken when the queue manager starts and shuts down, when logging space is running low, and after every 1000 operations logged.

Dual logging is not provided by WebSphere MQ for iSeries, UNIX, and Windows. However, OS/400 does provide mirroring, but the lowest level of granularity at which mirroring may be activated is the library. Thus, if mirroring is activated for your QMGRlib, not only would two of journal receivers be maintained, but also two sets of everything else contained in the QMGRlib. Mirroring can have performance implications.

Transition statement — The last group of WebSphere MQ implementations of logging and recovery is for the UNIX and Windows environments.




Uempty

Figure 5-17. Logging and recovery: UNIX and Windows WM101 / VM1011.0

Notes:

WebSphere MQ for Windows and UNIX systems use logging to harden messages on a queue. By default, the log is circular; it overwrites as it fills (unless uncommitted messages block it). This conserves space and reduces administration. However, if you want logging to offload to archives and recover from media failures, linear logging is an option. This decision must be made when a queue manager is created. It is not possible to alter the log strategy without creating the queue manager again.


Logging and recovery: UNIX and Windows

• Circular log– Crash recovery– Restart recovery

• Linear log– Crash recovery– Restart recovery– Media recovery

• Based on DB2 logging



Instructor Guide

Instructor notes:

Purpose — Logging and recovery in the UNIX and Windows environments.

Details — The queue manager records all persistent messages, changes to object definitions, and other significant events in the log.

There are two types of logs.

• A circular log consists of a ring of log files. When the first file is full, the queue manager moves on to the next, and so on, until all the files are full. The queue manager then goes back to the first file in the ring and starts again.

A circular log may be used for crash recovery, after a system failure has stopped the queue manager unexpectedly, or for restart recovery following a normal shutdown of the queue manager.

• A linear log consists of a continuous sequence of files in which space is not reused. As disk space is finite, some form of archiving may need to be considered.

A linear log may be used for crash recovery and restart recovery. However, unlike a circular log, it may also be used for media recovery; that is, the recovery of damaged queue manager objects.

A complete copy, or media image, of an object can be recorded in a linear log using the rcdmqimg command. The entry is called a media recovery entry.

If an object becomes damaged, the rcrmqobj command can be used to re-create the object by replaying the entries in the linear log from the media recovery entry.

The queue manager performs some, but not all, of this recording and recovery automatically.





Uempty


Notes:

WebSphere MQ uses facilities that probably are already familiar to you on your operating system.

While the products share a great deal of function across the various platforms, the appearance of WebSphere MQ on each platform is designed to feel familiar to users of that platform.


Unit summary

Having completed this unit, you should be able to:• List the system administration interfaces for WebSphere MQ• Describe the tasks for which a WebSphere MQ administrator is

responsible• Explain the concepts of logging and recovery• Describe some of the common administrative features of WebSphere

MQ



Instructor Guide

Instructor notes:

Purpose — Complete the unit on system administration.

Details — The system management guides have been combined because most of the function is shared. The installation processes are in separate manuals but they are relatively small. However, some operating-specific differences might remain so that they are easy to use by someone familiar with a particular operating system.





Uempty


Notes:

1. True of False: WebSphere MQ installation uses system-specific procedures for installing.

2. True or False: The first queue manager created on a system is the default.

3. Logging is used in which of the following queue managers? Select all that apply.

a. IBM WebSphere MQ for z/OS.b. IBM WebSphere MQ for HP-UX.c. IBM WebSphere MQ for iSeries, UNIX, and Windows.d. IBM WebSphere MQ for AIX.

4. On WebSphere MQ, which of the following interfaces are available for administration? Select all that apply.

a. ISPF panels.b. WebSphere MQ Explorer.c. Management from a user or vendor supplied MQI client.d. STRMQMMQSC.



1. True or False: WebSphere MQ installation uses system-specific procedures for installing.


3. Logging is used in which of the following queue managers? Select all that apply.a. IBM WebSphere MQ for z/OS.b. IBM WebSphere MQ for HP-UX.c. IBM WebSphere MQ for iSeries, UNIX, and Windows.d. IBM WebSphere MQ for AIX.

4. On WebSphere MQ, which of the following interfaces are available for administration? Select all that apply.a. ISPF panels.b. WebSphere MQ Explorer.c. Management from a user or vendor supplied MQI client.d. STRMQMMQSC.



Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty


Notes:

1. True of False: WebSphere MQ installation uses system-specific procedures for installing.

Answer: True.


Answer: False. You must specifically identify the queue manager as the default queue manager.

3. Logging is used in which of the following queue managers? Select all that apply.

a. IBM WebSphere MQ for z/OS.b. IBM WebSphere MQ for HP-UX.c. IBM WebSphere MQ for iSeries, UNIX, and Windows.d. IBM WebSphere MQ for AIX.

Answer: All of the above.



1. True or False: WebSphere MQ installation uses system-specific procedures for installing. Answer: True.

2. True or False: The first queue manager created on a system is the default.Answer: False. You must specifically identify the queue manager as the default

queue manager.3. Logging is used in which of the following queue managers? Select all

that apply.a. IBM WebSphere MQ for z/OS.b. IBM WebSphere MQ for HP-UX.c. IBM WebSphere MQ for iSeries, UNIX, and Windows.d. IBM WebSphere MQ for AIX.Answer: All of the above.



Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty


Notes:

4. On WebSphere MQ, which of the following interfaces are available for administration? Select all that apply.

a. ISPF panels.b. WebSphere MQ Explorer.c. Management from a user or vendor supplied MQI client.d. STRMQMMQSC.

Answer: All of the above.



4. On WebSphere MQ, which of the following interfaces are available for administration? Select all that apply.a. ISPF panels.b. WebSphere MQ Explorer.c. Management from a user or vendor supplied MQI client.d. STRMQMMQSC.Answer: All of the above.



Instructor Guide

Instructor notes:

Purpose —

Details —


Transition statement — The next unit reviews how IBM WebSphere MQ participates in unit-of-work processing.




Uempty
Unit 6. Transactional support
Estimated time

00:30


This unit provides an overview of the transactional support within WebSphere MQ.



• Describe how WebSphere MQ acts as a resource manager

• Explain how and when WebSphere MQ acts as a transaction manager

• Describe the programming implications of unit-of-work processing



References



© Copyright IBM Corp. 2011 Unit 6. Transactional support 6-1

Instructor Guide


Notes:

In this unit, you first examine the term unit of work and see what it means in WebSphere MQ. WebSphere MQ can coordinate its own resources and, in some cases, the resources of others. You look at these cases as well as consider how WebSphere MQ resources can be coordinated with other resources using an external transaction manager.


Unit objectives

After completing this unit, you should be able to:• Describe how WebSphere MQ acts as a resource manager• Explain how and when WebSphere MQ acts as a transaction manager• Describe the programming implications of unit-of-work processing




Uempty
Instructor notes:
Purpose — Introduce transaction processing.

Details — IBM WebSphere MQ can participate in unit-of-work processing in several ways:

• As a stand-alone resource manager, coordinating its own resources

• As a resource manager being managed with other resource managers by a transaction manager

• As a transaction manager, coordinating its resources and the resources of other resource managers

• On IBM WebSphere MQ for z/OS, batch applications can use IBM WebSphere MQ calls to coordinate its resources and other resource managers using Resource Recovery Services (RRS)

Transition statement — First, consider what a unit of work really is.



Instructor Guide

Figure 6-2. Unit of work WM101 / VM1011.0

Notes:

Within a unit of work, changes to resources are atomic. That is, either all of them take place and are committed, or none of them take place. There are no in-between states.

If there is a failure during a unit of work, changes to resources that have already been made are backed out, or rolled back. The same behavior is seen if the application determines that it cannot complete the unit of work for any reason.

The point at which changes to the resources within a unit of work are committed or backed out is known as a point of synchronization, or more simply a sync point. At a sync point, the data within the resources is in a consistent state from the point of view of the business and its applications.

The figure shows changes to queues and a database, but other resources such as files and working storage might also be affected.


Unit of work

UPDATE Q1 (MQGET)

UPDATE DB2 (SQL WRITE)

UPDATE Q2 (MQPUT)

COMMIT

Consistent state

Consistent state




Uempty
Instructor notes:
Purpose — To introduce the concept of a unit of work.

Details — A unit of work is a set of changes to resources, such as files, databases, queues, scratch pads, and so on. It is a unit because, no matter what happens, either all the changes take place, or none of them take place. The data within the resources would not be in a consistent state from the point of view of the business and its applications if only some of the changes were allowed.

The usual technique is to implement the unit of work in such a way that the updates are recorded before they take place. They do not actually take place until the unit of work is committed. When the unit of work is committed, it is considered complete and a new unit of work commences.

Additional information — The concept of unit-of-work processing is that, from the viewpoint of the business and its applications, all the changes made by a unit of work happen instantaneously at the time they are committed.

If commitment does not take place, perhaps because of a system failure, none of the updates take place. A message is not removed from the input queue, the database updates do not occur, and no message is put on the output queue.

An application might encounter a condition in which it cannot complete a unit of work and needs to back out changes it has already made to resources within the unit of work. So the backout process must be available under program control.

Choose for yourself how much of this content you are going to say to the students. Whatever you decide, the crucial thing is the lead-in to the next slide.

Transition statement — An application does not usually have direct access to resources such as queues and databases. Instead, it normally interacts with resource managers which own and manage the resources being accessed.



Instructor Guide

Figure 6-3. Resource manager WM101 / VM1011.0

Notes:

A resource manager is a generic term for software component that owns and manages resources such as files, databases, and queues. Typically, a resource manager provides:

• An API to allow an application access its resources • Functions to support the backup and recovery of its resources • Functions to support the creation and maintenance of its resources • Functions to support the commitment of changes to its resources within a unit of work,

or the backing out of such changes

Examples of resource managers include a DB2 database manager managing a set of tables, and a WebSphere MQ queue manager managing a set of queues.

An application can update resources belonging to more than one resource manager, as shown in the figure. In this case, it must issue a separate commit request to each resource manager. Unless some application action is taken, a separate commit request destroys the atomicity of the unit of work because the application or the system can fail between any two commit requests. The greater the number of resource managers, the more complex the application action must be.


Resource manager

Application

Resourcemanagers

CICSDB2

WebSphereMQ Queues

Tables

Files

Resources

Resourcemanagers

CICSDB2

WebSphereMQ

Resourcemanagers

CICSDB2

WebSphere MQ




Uempty
Instructor notes:
Purpose — To describe the function of a resource manager.

Details — On the figure, you see a CICS system managing some files under CICS file control, a DB2 database manager managing its tables, and a WebSphere MQ queue manager managing its queues. It is possible that an application could issue a request to commit the action of MQPUT and MQGET calls it made, and then fail before it can issue a request to commit the changes it made to DB2 tables. This failure implies that some additional application action is required to ensure the consistency of the data in the event of a failure.

Transition statement — A better solution is to use a software component that can coordinate the changes made to the resources of multiple resource managers within a single unit of work, as perceived by an application. Such a component of software is called a transaction manager, or a sync point coordinator.



Instructor Guide

Figure 6-4. Transaction manager WM101 / VM1011.0

Notes:

A transaction manager, or sync point coordinator, is a software component that can coordinate changes to the resources of multiple resource managers within a single unit of work as perceived by the application.

The implication of this is that an application only has to issue one request to commit the changes to all the resources even though multiple resource managers might be involved. In order to perform this function, a transaction manager uses a two-phase commit protocol in its interaction with the individual resource managers.

Say that an application issues a request to commit the changes it made to the resources of multiple resource managers. The transaction manager asks each resource manager to ensure that the changes to its resources are in a recoverable state. When each resource manager has confirmed that its resources are in a recoverable state, the first phase, known as the prepare phase, is complete.

When the prepare phase has completed successfully, the transaction manager can commit the unit of work and the second phase, known as the commit phase, begins. The commit phase is now the point of no return. The transaction manager asks each resource manager


Transaction manager

Application

Update Q1. . .

Update DB. . .

Update Q2

. . .

COMMIT

Q1

Tables

Q2

Resources

Resourcemanagers

CICSDB2

WebSphereMQ

Transactionmanager

Two-phase commit protocol




Uempty
in turn to commit the changes to its resources. Even if there is a system failure during this phase, commitment processing can recommence when the transaction manager and the resource managers are restarted because the changes to the resources are in a recoverable state.
Examples of transaction managers are CICS, IMS, Tuxedo, and Microsoft Transaction Manager.

The interface between a transaction manager and a resource manager needs to be standardized and documented if the aim is to make it easy to incorporate new resource managers as they become available. One such widely used interface is the X/Open XA interface, which uses a two-phase commit protocol. Transaction managers and resource managers that use this interface are said to be XA-compliant.



Instructor Guide

Instructor notes:

Purpose — To describe the function of a transaction manager, or sync point coordinator.

Details — Nothing in addition to the student notes.

Transition statement — Now that you have reviewed some basic concepts, independent of WebSphere MQ, you can investigate how WebSphere MQ functions operate within unit of work scenario. You begin by looking at the action of an MQGET call within a unit of work.




Uempty

Figure 6-5. MQGET within sync point control WM101 / VM1011.0

Notes:

In a previous topic, the get message options structure was introduced. One of the fields in this structure, Options, allows an application to specify one of more options that control the action of the MQGET call. Two of these options are within sync point control and outside of sync point control.

When an application issues MQGET outside of sync point control, the message is removed from the queue immediately and the application is then wholly responsible for it. The message cannot be made available again by backing out a unit of work.

However, if MQGET is issued within sync point control, the message is not removed from the queue immediately, but it is made unavailable or invisible to other applications. Only when the unit of work is committed is the message removed from the queue.


MQGET within sync point control

1 2 3

1 2 3

2 3

MQGET withinsync point control

Commit



Instructor Guide

Instructor notes:

Purpose — To explain the action of MQGET within sync point control and outside of sync point control.

Details — The sequence of events is:

1. Message 1 is retrieved within sync point control. This event is logged, the message is passed to the application, and the queue is updated to make message 1 invisible to other applications. Note, however, that the message is still on the queue and contributes to the value of the attribute CurrentQDepth, which in this case is 3.

The application processes the message and may issue further MQPUT and MQGET calls within sync point control.

2. The application then issues a request to commit the unit of work. The log is updated, the invisible message is removed from the queue, and the value of the attribute CurrentQDepth is decremented by 1.

Transition statement — Now look at the action of an MQPUT call within a unit of work.




Uempty

Figure 6-6. MQPUT within sync point control WM101 / VM1011.0

Notes:

Like the MQGET call, one of the parameters of the MQPUT call is the put message options structure. This structure also has a field called Options to allow an application to specify one or more options that control the action of MQPUT. Two of these options are within sync point control and outside of sync point control.

When an application issues an MQPUT call outside of sync point control, the message becomes available to other applications immediately and cannot be deleted by backing out a unit of work.

However, if MQPUT is issued within sync point control, the message is put on the queue, but remains unavailable or invisible to other applications until the unit of work is committed.


MQPUT within sync point control

1

1 2

1 2MQPUT within

sync point control

Commit

3

1 2 3

MQPUT withinsync point control

MQPUT withinsync point control



Instructor Guide

Instructor notes:

Purpose — To explain the action of MQPUT within sync point control and outside of sync point control.


Transition statement — Having seen how an application can issue MQPUT and MQGET calls within sync point control, you can now investigate what options an application has for committing and backing out a unit of work.




Uempty

Figure 6-7. Coordinating local units of work WM101 / VM1011.0

Notes:

A local unit of work is one in which the only resources being updated are the resources of the queue manager to which the application is connected.

To support the coordination of local units of work, IBM WebSphere MQ provides two MQI calls, MQCMIT and MQBACK. The MQCMIT call commits changes to WebSphere MQ resources that have been made since the last sync point. The MQBACK call rolls back changes to IBM WebSphere MQ resources that have been made since the last sync point. Only changes to resources made under sync point control are affected by the MQCMIT and MQBACK calls.

The figure shows an example of a server program that gets a request message from a queue and puts a reply message on a reply-to queue within a local unit of work. This guards against the possibility of losing the request message if there is a system failure while the server program is processing it.

A WebSphere MQ client application can also use the MQCMIT and MQBACK calls.


MQGET message from server queue

MQPUT extra requests

MQPUT reply message

.

.

.

if error …

MQBACK

if OK …

MQCMIT


MQPUT extra requests

MQPUT reply message

.

.

.

if error …

MQBACK

if OK …

MQCMIT

Coordinating local units of work

• A local unit of work is one in which the only resources being updated are those of the queue manager



Instructor Guide

Instructor notes:

Purpose — To explain the concept of a local unit of work and to introduce the MQCMIT and MQBACK calls.

Details — MQBEGIN is not used when coordinating only local units of work.

Transition statement — What happens if an application is updating the resources of another resource manager, as well as putting messages on queues and getting messages from queues?




Uempty

Figure 6-8. Internal coordination of global units of work WM101 / VM1011.0

Notes:

A global unit of work is one in which the resources of other resource managers are being updated, as well as the resources of a queue manager.

The coordination of global units of work may be internal or external to the queue manager. You look at the external coordination of global units of work a little later. On the figure, you focus on internal coordination.

Using the X/Open XA interface, a queue manager is able to coordinate changes to its own resources and to other resource managers within a unit of work. An external sync point coordinator is not required under these circumstances.

The figure depicts an example of a global unit of work in which changes are made to WebSphere MQ resources and to a relational database within a unit of work. The MQCMIT and MQBACK calls are used to commit and roll back changes, as with local units of work. However, when coordinating global units of work, the MQBEGIN call is needed in order to start a unit of work.


MQBEGIN


EXEC SQL INSERT data base record

MQPUT reply message

.

.

.

if error …

MQBACK

if OK …

MQCMIT

MQBEGIN


EXEC SQL INSERT data base record

MQPUT reply message

.

.

.

if error …

MQBACK

if OK …

MQCMIT

Internal coordination of global units of work

• A global unit of work is one in which the resources of other resource managers are also being updated



Instructor Guide

Instructor notes:

Purpose — To explain what is meant by a global unit of work, to understand the options for coordinating a global unit of work, and to introduce the MQBEGIN call.

Details — An XA-compliant transaction manager communicates with a WebSphere MQ queue manager using the same MQI channel as the client application. All “xa-” calls are routed to the queue manager for action and response.

Transition statement — Next, you look at which XA-compliant database managers are supported by IBM WebSphere MQ.




Uempty

Figure 6-9. Database coordination WM101 / VM1011.0

Notes:

The figure lists the XA-compliant database managers that are supported by WebSphere MQ. These database managers may participate in a global unit of work coordinated by a WebSphere MQ queue manager.

The figure also lists some restrictions regarding the internal coordination of global units of work.

• A WebSphere MQ client application cannot participate in a global unit of work and cannot therefore issue the MQBEGIN call.

• A queue manager can be XA-compliant, both as a sync point coordinator and as a resource manager. It is not possible to configure two or more queue managers as participants in a global unit of work; an application can only be connected to one queue manager at a time.

• Normally, updates to WebSphere MQ resources and to the resources of a database manager must be made on the same system. WebSphere MQ cannot coordinate a distributed unit of work.


Database coordination

• Supported database managers– DB2 Universal Database– Informix– Oracle– Sybase

• Restrictions– A WebSphere MQ client cannot participate in a global unit of work, unless it is

the extended client version– Only one queue manager can participate in a global unit of work – Normally, updates to WebSphere MQ and database resources must be made on

the same system– A database server can be on a different system, provided it can supply an XA-

compliant client feature



Instructor Guide

• A database manager can reside on a different system than the queue manager, provided it can supply an XA-compliant client feature that resides on the same system as the queue manager.




Uempty
Instructor notes:
Purpose — To indicate which XA-compliant database managers are supported by IBM WebSphere MQ, and to explain the restrictions which apply to the internal coordination of global units of work.


Additional information — If you have a requirement to coordinate global units of work, but you are not using a supported queue manager and database manager, you need to use an external sync point coordinator. The Extended WebSphere MQ Client also needs an external sync point coordinator.

Transition statement — With the announcement of WebSphere MQ for z/OS V2.1, a new coordination capability was introduced for the batch or TSO environment — RRS.



Instructor Guide

Figure 6-10. WebSphere MQ for z/OS RRS support WM101 / VM1011.0

Notes:

In addition to the two-phase commit capabilities available in the CICS and IMS environments, WebSphere MQ batch programs can participate in units of recovery managed by z/OS Recoverable Resource Manager Services (RRS).

MQPUTs and MQGETs are still used to specify the sync point option that you want to use. It is even possible to use the MQCMIT and MQBACK verbs. The alternative is using SRRCMIT and SRRBACK. Linking with a different stub enables this choice. Single-phase (non-RRS) processing is also still available.


WebSphere MQ for z/OS RRS support

MQGET (MQGMO_SYNCPOINT)..DB2 UPD (using Syncpoint)MQPUT (MQPMO_SYNCPOINT)....MQCMIT (or MQBACK)

orSRRCMIT (or SRRBACK)




Uempty
Instructor notes:
Purpose — To introduce RRS support.


Additional information — None.




Instructor Guide

E


Notes:

Unit-of-work processing allows control over the delivery of messages. Messages are delivered when the application is satisfied that related processing has been successful. In addition, it allows for backing out of any updates to queues in case of errors.

WebSphere MQ, in addition to using MQCMIT and MQBACK to coordinate its own resources, can take part in a unit of work that is coordinated among several resource managers under control of a transaction manager. A queue manager can also, sometimes, be a transaction manager of sorts.

Unit-of-work processing is an important consideration in the application design process.


Unit summary

Having completed this unit, you should be able to:• Describe how WebSphere MQ acts as a resource manager• Explain how and when WebSphere MQ acts as a transaction manager• Describe the programming implications of unit-of-work processing




Uempty
Instructor notes:
Purpose — Provide a review of what has been covered in Unit 6.

Details — IBM WebSphere MQ has three calls associated with unit-of-work processing — MQBEGIN (for distributed queue managers), MQCMIT, and MQBACK. MQBEGIN is only used when identifying the start of a global unit of work (including either Sybase, Oracle or DB2 updates). The actual commit or rollback still uses MQCMIT or MQBACK.

IBM WebSphere MQ for z/OS, in the batch environment supporting RRS, alternatives to the MQCMIT and MQBACK calls are SRRCMIT and SRRBACK.

If an application is running in an environment with a transaction manager (that is CICS or ENCINA), a call to MQCMIT or MQBACK fails. It is expected that the transaction manager handles unit of work coordination.




Instructor Guide


Notes:

1. True or False: Within a unit of work, changes are atomic.

2. An MQPUT within sync point control means:

a. Messages are not placed on a queue until the commit.b. Messages are placed on the queue and the “getting” program needs to check the

sync point flag.c. Messages are placed on the queue but are not available to the getting program until

after the commit.

3. True or False: Standard WebSphere MQ clients can use global unit-of-work processing.




2. An MQPUT within sync point control means: a. Messages are not placed on a queue until the commit.b. Messages are placed on the queue and the “getting” program needs to check

the sync point flag.c. Messages are placed on the queue but are not available to the getting

program until after the commit.





Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide


Notes:


Answer: True.

2. An MQPUT within sync point control means:

a. Messages are not placed on a queue until the commit.b. Messages are placed on the queue and the “getting” program needs to check the

sync point flag.c. Messages are placed on the queue but are not available to the getting program until

after the commit.

Answer: c


Answer: False.


Checkpoint answers

1. True or False: Within a unit of work, changes are atomic. Answer: True.

2. An MQPUT within sync point control means: a. Messages are not placed on a queue until the commit.b. Messages are placed on the queue and the “getting” program needs to check

the sync point flag.c. Messages are placed on the queue but are not available to the getting

program until after the commit.Answer: c.

3. True or False: Standard WebSphere MQ clients can use global unit-of-workprocessing.Answer: False.




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide




Uempty
Unit 7. Security
Estimated time

00:30


This unit describes the security aspects of the IBM WebSphere MQ platforms.



• Describe security features of the WebSphere MQ platforms

• Determine which security features are appropriate in a given environment

• Explain the role of WebSphere MQ security within and across enterprises



References



© Copyright IBM Corp. 2011 Unit 7. Security 7-1

Instructor Guide


Notes:

IBM WebSphere MQ is a resource manager, but does not claim to be a security manager. However, security is important in an enterprise and IBM WebSphere MQ certainly participates. It relies on IBM WebSphere MQ skills.

The purpose of this unit is to identify the various aspects of the IBM WebSphere MQ product that can participate in the overall security management of your installation.


Unit objectives

After completing this unit, you should be able to:• Describe security features of the WebSphere MQ platforms• Determine which security features are appropriate in a given

environment• Explain the role of WebSphere MQ security within and across

enterprises




Uempty
Instructor notes:
Purpose — Introduce the security mechanisms.

Details — Some platforms have strong security mechanisms; z/OS has SAF interface, for example. Some have only mechanisms based on the platform file server security.

This topic looks at the security architectures, and then at the implementations.

Transition statement — To begin at the beginning, you need to look at the goals and architectures of security.



Instructor Guide

Figure 7-2. IBM security architecture WM101 / VM1011.0

Notes:

Security services are those functions that, when provided in a systems environment, serve to ensure the protection of resources by enforcing the defined security policies of the organization. Security mechanisms are technical tools and techniques used to implement the security services. Mechanisms can operate individually, or together with others, to provide a particular service. The security objects consist of two components: managed objects and managing objects. Managed objects describe what is managed and how it behaves. The definition of managed objects includes specifying their attributes and their behavior, which provides a concrete description of what is manageable. The method of management is defined by managing objects consisting of applications and data, which support the management and use of the rest of the system.

Security management is the administration, control, and review of an enterprise security policy. Security managers use procedures and system security services to implement policies consistent with the organization objectives. System auditability can provide checks and balances on system users and administrators to ensure that security management policies are enforced.


IBM security architecture

Security services

Security objects

Security mechanisms

Management

Servicesmanagement

Mechanismsmanagement

Objectmanagement

Policy management

Audit management

Identification and authentication

Accesscontrol

Confidentiality

Data integrity

Non-repudiation

Entityauthentication

Security labels

Access controllist

Messageauthentication

Encipher and decipher

Digitalsignature

Modificationdetection

Users

Groups

Privileges

Auditlogs

Programs

Encryptionkeys

Passwords

Others




Uempty
Instructor notes:
Purpose — System security management is the management of the security aspects of the overall open systems environment, including:

• Security policy management (creation and maintenance of security profiles for users and resources, and secure system integrity specifications)

- Security audit management - Security recovery management - Security alert management

• Security services management is the management of specific security services, including interaction with other security service management functions and security mechanisms management functions. An example is the enabling of the access control service.

• Security mechanisms management is the management of specific security mechanisms, such as the setting of access control list (ACL) parameters.

• Security object management is the registration of security objects with appropriate authorities (security domains, security policies, security labels, and cryptographic algorithms).

Security services

• Identification and authentication facilities verify the identity of individuals. The basic function uniquely identifies users and programs, verifies these identities, and assures individual accountability. Authenticated user identification provides the basis for additional security functions, such as access control and auditing. Authentication technology can take the form of passwords, smart tokens, smart card, and biometric measuring devices.

• Access control protects critical resources by limiting access to only authorized and authenticated users.

• Data integrity provides detection of the unauthorized modification of data.

• Non-repudiation can be viewed as an extension to the identification and authentication services. The non-repudiation service can protect a recipient against the false denial by an originator that the data has been sent. It can protect an originator against the false denial of a recipient that the data has been received. The goal is to verify that a particular message can be associated with a particular individual.

Security mechanisms

• Entity authentication verifies the identity of the entity by comparing identification information provided by the entity to the content of a known and trusted information repository.



Instructor Guide

• Access control lists are information repositories that contain data relative to the rights and permissions of access granted to each authenticated identity known to the system. Security labeling provides a mechanism to enhance or refine the levels of control imposed on a resource or entity, by defining specific controls on the label tag itself.

• Cryptography provides the confidentiality service. It is also used often to complement some other mechanisms to provide total security solutions. Enciphering and deciphering transform data or information from an intelligible format, to an unintelligible format, and back to an intelligible format. Cryptography is basically a mathematical process using keys and algorithms that apply the key values against the data in a predetermined method.

• Data integrity is supported by the use of checking code. Three methods of calculating the checking code are in common use: cyclic redundancy check (CRC), modification detection codes (MDC), and message authentication codes (MAC). In addition to data integrity, non-repudiation services such as digital signature are becoming important to many customers. Digital signatures provide proof of data origin, proof of delivery, or both. The first service provides the recipient with proof of the data sender.

Security objects

• Some examples of security objects might include:

- User profiles (user IDs, group definitions) - User authorization (to resource) - Cryptographic keys - Security labels






Uempty

Figure 7-3. Security implementation WM101 / VM1011.0

Notes:

Although there are mechanisms in the surrounding environment, in the operating systems, networks, and transaction managers, you are most interested in the facilities provided by the queue managers and in applications that they support.

The queue managers allow for complementary security services, but they rely on the environment in which they are running to provide the mechanisms that are required. For example, on z/OS, WebSphere MQ queue managers use the Resource Access Control Facility (RACF) or an equivalent product to provide access control for queue manager resources (queues, commands, and so on).


Security implementation

• Mechanisms required at various levels– Application code and exits– Product code– Environment code– Network code

Queue managerObject authority managers

exits

NetworkingSSL

firewalls

EnvironmentSecurity managers

Application codeSecurity context information



Instructor Guide

Instructor notes:

Purpose — Introduce the areas in which security is implemented.

Details — From this picture, it is clear that there is no one place to implement all of the possible security mechanisms. Each application component and each IBM product provides a part.

Distributed security is a much wider topic that cannot be fully covered in this presentation. However, it is important to be aware that IBM is actively pursuing solutions with both technology and products.

Some required services can be related to an IBM WebSphere MQ environment:

1. Identification — CICS/IMS logon and WebSphere MQ connection security.2. Access — WebSphere MQ command, resource security, and channel access control.3. Confidentiality — Can be enhanced using WebSphere MQ transmission exits.4. Data integrity — Can be verified in WebSphere MQ exits.5. Non-repudiation — See later examples of WebSphere MQ context security

(confirmation of message arrival and delivery enhance this feature).

IBM WebSphere MQ offers facilities for a total security policy to be implemented as required. You look at these WebSphere MQ facilities next.

Transition statement — What security does IBM WebSphere MQ offer?




Uempty

Figure 7-4. Security in WebSphere MQ WM101 / VM1011.0

Notes:

IBM WebSphere MQ provides:

• Access control — Check when accessing queue manager resources, channels, and commands against the user ID under which the application program is running. z/OS uses an external security manager as RACF, iSeries system security for OS/400, or OAM for Windows. Access control can include the following:

- Checking the user ID when the MQCONN, MQOPEN, MQPUT1, and MQCLOSE calls are issued.

- Checking access to commands as they are issued to determine whether the issuing user has appropriate permissions.

- Performing additional checks when commands are issued to determine whether the issuing user has the appropriate permissions for the actual resource to which the command is being directed.

- Checking access to channels based on IP address or user name.


Security in WebSphere MQ

• Access control– Resources– Commands– Channels

• Message context carried with message

• API• SSL

• Message channel agent – Security– Message– Send and receive

• Object authority managers– Internal– External



Instructor Guide

• Message context — Contextual information contained within the WebSphere MQ message descriptor of each message, which describes who generated the original request and where this specific message came from.

• MCA exits — Exit programs can be attached to the message channel agents. This exit facility is designed to allow security-related functions to be implemented in the exit routines associated with links between systems. Today, some exit programs are supplied with some WebSphere MQ products.

• Secure Sockets Layer (SSL) provides channel security to the user, as-is. It is an industry-standard protocol for transmitting data in a secure manner over an insecure network. SSL is widely deployed in both Internet and intranet applications. IBM WebSphere MQ support for SSL enables you to specify, on the channel definition, that a particular channel uses SSL security.

• API-crossing exit is invoked before and after every MQI call. Available only for CICS applications under z/OS. Using the API-crossing exit can degrade WebSphere MQ performance, so its use needs to be planned carefully.

• Security management and audit — Facilities for system administrators to set up and manage the various security operations, and to verify that the security facilities are working in the expected manner.




Uempty
Instructor notes:
Purpose — Provide an overview of security in IBM WebSphere MQ.

Details — As previously stated, IBM WebSphere MQ does not and cannot provide a total security solution, but it works with the operating system, transaction manager, networking software, and so on. This figure is a summary of IBM WebSphere MQ facilities.

Transition statement — Take a closer look at some of the API security features available.



Instructor Guide

Figure 7-5. Resource access security WM101 / VM1011.0

Notes:

Security involves the protection of the queue manager resources from unauthorized access. In addition to checking that the user is able to connect to the queue manager, checks can be done to ensure that the user is only requesting options that are authorized.

For instance, an application might issue an MQOPEN for output and the user is permitted to do that. However, if the option is changed to open the queue for output and to set context fields (those containing user ID information), the call might fail.

In addition to wanting to change the contents of the context fields in an individual message, a program can use the user ID context information from an incoming message.

The namelist and process objects can be opened by an application for inquiry. The namelist and process objects can also be checked to determine whether the user is permitted.


Resource access security

• Queue security– User IDs– Options

• Process security

• Namelist security

• Context security– MQOPEN, MQPUT1

• Channel access control

• Alternate user security




Uempty
Instructor notes:
Purpose — Provide an API security overview.

Details —

Context Security

An application must be authorized to set or change the context fields contained within message descriptors.

Alternate User Security

An application program can request an alternate user ID (specified on the MQOPEN call) to check the authorization for opening a queue, in place of the current user ID. However, the application must be authorized to make this type of request.

Typically, an application issues an MQOPEN call, for example, specifying “use alternate user ID = USER2”. The MQOPEN call only succeeds if both of the following conditions are met:

• The application has been authorized for the use alternate user ID option. • The alternate user ID (USER2) is authorized to open the object for the specified

options.

A server application, for example, might use this feature to specify the user ID taken from the context field of a message that it has retrieved.


Command Security

Provides normal OS/400 authorization to use CL commands. GRTMQMAUT provides resource authority.

Transition statement — There is also security imposed on commands.



Instructor Guide

Figure 7-6. Command security WM101 / VM1011.0

Notes:

As mentioned previously, checks can be performed to determine whether a user is permitted to issue certain commands. In addition, the check can also be whether the user is authorized to issue the command against a specific resource.


Command security

• Authorization checked when command is issued

• Based on user ID

• Command security: Can this user issue this command? Example: DISPLAY QUEUE

• Command resource security: Can this user change this resource? Example: DELETE QLOCAL('Payroll')




Uempty
Instructor notes:
Purpose — Describe command security.

Details — Command security does not apply to all platforms. iSeries, for example, uses the GRTMQMAUT command to provide command resource authority. z/OS uses RACF, or an equivalent security manager, for the same purpose.

Additional information — The DISPLAY command does not allow checking down to the resource level.

Transition statement — Here are more details on security as it pertains to message context.



Instructor Guide

Figure 7-7. Message context WM101 / VM1011.0

Notes:

The first three fields in the message context are treated as a group called identity context. The remaining fields in the message context are known as origin context.

The message context allows not only a user to be authenticated and authorized, but the application that actually performed the MQPUT can be checked as well.

Unless it is permitted and opened with the options to update them, an application cannot update these fields. The queue manager completes the information when the MQPUT is executed.


Message context

• Travels with the message in message descriptor

• Allows system authorization by user ID

• Provides accounting structure• Allows application authorization

• Identity context– User ID – Accounting token– Application identity data

• Origin context– Application name– Type– Date and time– Application origin data




Uempty
Instructor notes:
Purpose — Provide an overview of message context.

Details — Message context is contained within each message descriptor.

The context facilities allow an application program that is retrieving a message to find more information about the origins of that message.

Message context would normally contain the user ID and accounting information for the user who made the original request, and the name and type of program that generated this message.

The user ID in the message context can be used for access control purposes (on MQPUT, for example) instead of using the user ID that is associated with the program that issues the MQPUT call.

A program can only set or change the context of a message if it has been given authority to do so. By default, an application program can request that the message context is set to either (1) the default context value or (2) the no context value.

Additional information — Not all platforms enforce context security. This statement implies that it would be possible for a program running on some platforms to be able to complete these fields. Therefore, it is important to understand which platforms enforce security on message context data, which ones do not, and what can happen if those platforms have to intercommunicate.

Transition statement — You have talked in detail about user ID. Look at some examples.



Instructor Guide

Figure 7-8. User IDs WM101 / VM1011.0

Notes:

Many systems operate under user IDs, often associated with passwords. Those systems that do not, might have some comparable identifier, such as an ID associated with an address space in z/OS or a Windows or UNIX process. These other identifiers can be used to check for authorized access.

It is possible that an attempt to access a resource might result in a message being delivered to the security manager log. It is also possible that such a message is placed in the queue manager logs. If it is enabled, the unauthorized access can also be recorded as a message on a system queue.


User IDs

• Operating system user ID

• Address-space identifier

• Console ID

• Access violations logged to– Environment log – Queue manager log– Queue manager event queue




Uempty
Instructor notes:
Purpose — Describe user IDs.

Details — These are just samples.

User ID authentication varies widely from platform to platform.

Most violations are logged in the queue manager log, but MQCONN violations are logged in the system-wide log.

Security can be switched on and off for each of the security types (queue, process, command, and so on).

Transition statement — Review what IBM WebSphere MQ provides as the current channel security, which is not provided to the user as-is.



Instructor Guide

Figure 7-9. Passing context information WM101 / VM1011.0

Notes:

In the example in the figure, messages have split, been processed by different systems, and then rejoined for a request to be sent to the database server.

Under whose authority should the final database calls be made?

It seems that the user ID that starts application D is the one checked for authority to open the database update queue for output. However, it is possible to pass the initial user ID all the way from the user that started application A and issued MQPUTs to the three output queues. This user can then be checked to determine whether it is authorized to perform database updates.

Notice the continuum across the bottom. Commands are controlled at a local level, as is access control in programs (MQOPEN, for instance). When the data starts to flow across networks, the use of security exits can ensure that the MCAs on each side of a channel establish trust that they are connecting to the proper partner. As data flows, additional exits can be used for encryption and decryption to protect messages that contain sensitive information. Finally, the context information can aid in assuring that only authorized users obtain access to critical resources.


Passing context information

A

E

C

B D

Commands

Access control

Authentication

Encryption and decryption

Message context

Queue 4

Queue 5

Queue 1

Queue 2

Queue 3

?

Database




Uempty
Instructor notes:
Purpose — Illustrate the need to carry context with a message.

Details — In this example, a user invokes a program in the system to the left. The request causes messages to be placed on three queues. Two of the messages are further processed by different systems in the middle, and the third goes directly to the system on the right. This process joins the results of the messages. It sends the resulting message to the database server at the bottom to generate an update of the database.

Under whose authority should this run?

Actually, the answer is not entirely straightforward, but there are certainly cases where the answer is that of the client on the left. You need to be able to carry context with the message that identifies that client.

Transition statement — You saw the various channel exits when you covered intercommunication. Look at one example a bit more closely.



Instructor Guide

Figure 7-10. WebSphere MQ channel security WM101 / VM1011.0

Notes:

The uses of message channel agent exits are:

Security exit is primarily used by the MCA at each end of a message channel to authenticate its partner.

Send and receive exits can be used for purposes such as data compression and decompression, or data encryption and decryption.

Message exit can be used for any purpose that makes sense at the message level. The following are some examples:

• Application data conversion • Encryption and decryption • Additional security checks, such as validating an incoming user identifier • Substitution of one user identifier for another as a message enters a new security

domain


WebSphere MQ channel security

MCAMCAChannel

Message flow

Security Security

Message Message

Send Receive

Authentication

Integrity

Non-repudiation

Encryption




Uempty
Instructor notes:
Purpose — Explain the channel security and how it is implemented via MCA exits.

Details — The processing of these channel exits is as follows:

1. The security exits are called after the initial data negotiation between both ends of the channel. Security exits must end successfully for the startup of the channel and the flow of messages to be allowed.

2. The message exit is called by the sending MCA, and then the send exit is called for each part of the message that is transmitted to the receiving MCA.

3. The receiving MCA calls the receive exit when it receives each part of the message, and then calls the message exit when the whole message has been received.

The message-retry exit is used to determine how many times the receiving MCA attempts to put a message to the destination queue before taking alternative action. (This exit is not supported on IBM WebSphere MQ for z/OS.)


Transition statement — How can IBM WebSphere MQ take advantage of secure message transport over an insecure network? By using SSL — Secure Sockets Layer.



Instructor Guide

Figure 7-11. Secure Sockets Layer (SSL) WM101 / VM1011.0

Notes:

Secure Sockets Layer (SSL) is common across all the platforms: z/OS, UNIX, Windows, and iSeries.

SSL is an industry-standard protocol for secure communications, involving encryption, authentication, and integrity of data. SSL is supported in both client/server and queue manager-to-queue manager channels (including queue manager clusters). There are many flexible capabilities that are built in, including the ability to select from whom they are prepared to accept communications, based on their fully authenticated identity. SSL removes, for many people, the need to set up channel exits, where they were used for security purposes.

SSL is widely accepted in the Internet community, and has been subjected to significant testing by the hacker community, such as eavesdropping, impersonation, and tampering.


Secure Sockets Layer (SSL)

• Protocol to allow transmission of secure data over an insecure network– Encryption, integrity, authorization– Protection for client/server, queue manager, and queue manager channels

• To combat security problems– Eavesdropping– Tampering– Impersonation




Uempty
Instructor notes:
Purpose — To describe Secure Sockets Layer (SSL).

Details — SSL is an industry-standard protocol that provides a data security layer between application protocols and the communications layer, such as TCT/IP. The SSL protocol was designed by Netscape Development Corporation and is widely deployed, in both Internet and intranet applications. SSL defines methods of data encryption, server authentication, message integrity, and client identification for a TCP/IP connection.

Additional information — Detailed information about Secure Sockets Layer (SSL) is available in the WebSphere MQ Security manual.

Transition statement — All security accesses need to be monitored and audited. If a security access failure is logged but goes unnoticed, you may be overlooking a problem.



Instructor Guide

Figure 7-12. Management and audit tasks WM101 / VM1011.0

Notes:

The types of tasks listed in the figure can be a shared job between the WebSphere MQ administrator and the security team, depending on your organization. It is doubtful that some of the items listed are handled outside of the security group. However, the WebSphere MQ administrator needs to have accurate information to ensure that WebSphere MQ security is properly set up.


Management and audit tasks

• Management actions– Set up and change access control lists– Enable or disable security checks– Create and monitor user ID timeouts – User ID verification– Password monitoring

• Audit– Violation messages on job log– Violation queue monitoring– Access list




Uempty
Instructor notes:
Purpose — Describe the management actions that are required.

Details — The information listed is a general view of the types of responsibilities that may need to be considered for a WebSphere MQ administrator.

Transition statement — Next, you look at an example of how an alternate user ID could be used to authorize an application WebSphere MQ request.



Instructor Guide

Figure 7-13. Using user ID context and alternate user ID WM101 / VM1011.0

Notes:

As you look at the example, consider that Julie and Mary both work in a department that enters requests for information, orders, and account updates. However, based on experience, Julie is authorized to do all three, while Mary is only permitted to enter orders and inquire.

The process is:

1. Users at workstations place requests on the ACME-Q.

2. The server application ASERV generates individual updates, orders, or inquiries in the relevant queues for processing.

3. Anyone can inquire and any ACME employee can place orders, but only JULIE is allowed to update. In this example, JULIE is initiating an update.

4. The simplified message header context information indicated here shows JULIE as the identity and ACPROG as the origin information.

5. The server program opens the update queue using an alternate ID.


Using user ID context and alternate user ID

ID=JULIE

ACPROG

ID=MARY

ACSERV

ID=AC27

UPDATE

INQUIRY

ORDERS

JULIE ACPROG

ACME-Q

UP_Q

INQ_Q

ORD_Q

ACPROG




Uempty
Instructor notes:
Purpose — Provide an example of the alternate user ID.

Details — There is a two-stage check: Does ID AC27 have authority to use an alternate-ID? Does JULIE have authority to access the update queue?

The application design in the ACME Tool Manufacturing Company z/OS CICS system uses the split-join technique. The ACSERV program gets messages from the ACME_Q queue, and puts a message to either the UP_Q, INQ_Q, or ORD_Q queue.

The ACSERV program needs alternate user authority to use the user ID taken from the message context of the message that is obtained from the ACME_Q queue. The value of this user ID is then used at MQPUT time to verify that the user ID is authorized to put messages on that queue.

Transition statement — Now, however, it is decided to allow limited access to employees of US Tool Hire, Inc.



Instructor Guide

Figure 7-14. Using channel message exit WM101 / VM1011.0

Notes:

Now, ACME wants to allow employees of US Tool Hire, Inc. to have limited access to the order application. They do not need to know anything about US Tool Hire's employees. How can ACME handle this scenario using IBM WebSphere MQ capabilities?

Consider the use of message exit and MQMD context information.


Using channel message exit

ACSERV

UPDATE

INQUIRY

ORDERS

QM2

MCA

EXIT

ACME Tool CompanyUS Tool Hire, Inc. Company

ALOIS

LANA

HIRAM

QM1

Changemessagecontext values




Uempty
Instructor notes:
Purpose — Describe using channel exits for added protection.

Details — The ACME Tool company now wants to allow employees of the USTOOL Hire Company to place orders directly by sending messages to the ORD_Q.

1. On the right, you have the same z/OS environment seen in the previous diagram.

2. In addition, there is now the US Tool company with a link into ACME.

3. US Tool has their own applications, and their own user group — all potentially changing dynamically.

4. ACME does not want to maintain lists pertaining to US Tool, but it does want security. Requests must come genuinely from US Tool and are accepted in good faith; that is, orders cannot later be denied by US Tool (repudiated).

5. US Tool must have proper access control and authorization within their own environment or risk orders being fulfilled for which they take full responsibility.

MCA security exit ensures that the link to US Tool is genuine.

MCA message exit substitutes a generic identity context for all US Tool orders.

The MCA program uses the “set all context” option on MQPUT when putting messages to the ACME_Q queue. In order to “set all context”, the MCA program needs to be given authority.

The ACME Tool company only needs to add USTOOL to the access control list associated with the ORD_Q queue. This action allows any message that has USTOOL in the message context to be placed on that queue.




Instructor Guide


Notes:

This unit introduced the topic of security and its role with WebSphere MQ. The implementation of security is an important consideration. It should be part of early planning, and involve the security management administration staff to ensure that there is a clear understanding of the IBM WebSphere MQ requirements as well as the standards of the organization.


Unit summary

Having completed this unit, you should be able to:• Describe security features of the WebSphere MQ platforms• Determine which security features are appropriate in a given

environment• Explain the role of WebSphere MQ security within and across

enterprises




Uempty
Instructor notes:
Purpose — Finish the security topic.

Details — Security is an unpleasant but necessary consideration in most companies. Since the queues, processes, and other IBM WebSphere MQ objects need to be considered as business critical resources, the implementation of effective security procedures is essential.

The WebSphere MQ Security manual offers guidance regarding security on various IBM WebSphere MQ platforms.




Instructor Guide


Notes:

1. There are various services involved in a security implementation; with which one is WebSphere MQ most concerned?

a. Authentication.b. Authorization.c. Access control.

2. True or False: Usually, a site security administrator sets up all the security for WebSphere MQ objects.

3. Context security is used to:

a. Check that users can access WebSphere MQ programs.b. Tell the MCA where to deliver the message.c. Allow programs to set up their authorization.d. Enable access to queues to be controlled on a message-by-message basis.

4. True of False: After an application puts a message on a queue and receives a successful completion code, there is no way to tell who created the message.



1. There are various services involved in a security implementation; with which one is WebSphere MQ most concerned? a. Authentication.b. Authorization.c. Access control.


3. Context security is used to: a. Check that users can access WebSphere MQ programs.b. Tell the MCA where to deliver the message.c. Allow programs to set up their authorization.d. Enable access to queues to be controlled on a message-by-message basis.





Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide


Notes:

1. There are various services involved in a security implementation; with which one is WebSphere MQ most concerned?

a. Authentication.b. Authorization.c. Access control.

Answer: c. WebSphere MQ leaves authentication and authorization to the security manager.


Answer: False. In most cases, a WebSphere MQ administrator performs this task, in consultation with a security administrator.



1. There are various services involved in a security implementation; with which one is WebSphere MQ most concerned? a. Authentication.b. Authorization.c. Access control.Answer: c. WebSphere MQ leaves authentication and authorization to the

security manager.

2. True or False: Usually, a site security administrator sets up all the security for WebSphere MQ objects. Answer: False. In most cases, a WebSphere MQ administrator performs this

task, in consultation with a security administrator.




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide


Notes:

3. Context security is used to:

a. Check that users can access WebSphere MQ programs.b. Tell the MCA where to deliver the message.c. Allow programs to set up their authorization.d. Enable access to queues to be controlled on a message-by-message basis.

Answer: d.


Answer: False.



3. Context security is used to: a. Check that users can access WebSphere MQ programs.b. Tell the MCA where to deliver the message.c. Allow programs to set up their authorization.d. Enable access to queues to be controlled on a message-by-message basis.

Answer: d.


Answer: False.




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide




Uempty
Unit 8. Linking, bridging, and the WebSphere MQ family
Estimated time

00:30


This unit includes a brief overview of the various linking and bridging mechanisms that are available to further expand the scope of messaging and queuing in an enterprise.



• List the various links and bridges used with WebSphere MQ

• List other functions and products that make up the WebSphere MQ family

• Describe the publish/subscribe functionality



References



© Copyright IBM Corp. 2011 Unit 8. Linking, bridging, and the WebSphere MQ family 8-1

Instructor Guide


Notes:

Over the past few years, IBM WebSphere MQ has become an essential part of many IT infrastructure. Because of its strength, WebSphere MQ has been used in several implementations that allow assured delivery of information between many different environments. In many cases, the underlying messaging and queuing mechanism is transparent, not only to the user, but to the programmer as well.

You take a brief look at the various links, bridges, functions, and products that make up the WebSphere MQ family.


Unit objectives

After completing this unit, you should be able to:• List the various links and bridges used with WebSphere MQ• List other functions and products that make up the WebSphere MQ

family• Describe the publish/subscribe functionality




Uempty
Instructor notes:
Purpose — Provide context for this final topic.

Details — The following links, bridges, and complementary products are included:

• IMS bridge

• CICS DPL bridge

• CICS 3270 bridge

• The link for SAP R/3

• IBM WebSphere MQ Everyplace

• IBM WebSphere MQ publish/subscribe

• IBM WebSphere Business Integration Adapters

• IBM WebSphere Message Broker

Additional information — On completion of this unit, the student should have a high-level idea of each of the products. As you proceed, references to related documentation are provided.

Transition statement — First, discuss the IMS bridge.



Instructor Guide

Figure 8-2. The IMS bridge WM101 / VM1011.0

Notes:

The WebSphere MQ-IMS bridge allows direct access to IMS applications from WebSphere MQ applications. This means that the IMS applications can be included in an IBM WebSphere MQ solution without any rewriting, recompiling, or relinking.

No MQI calls are required in the IMS applications. The sending application uses a special header as part of the messages intended for the IMS applications.

The IMS bridge is an IMS Open Transaction Manager Access (OTMA) client. OTMA is a connectionless client/server protocol that is transaction-based and functions as an interface for accessing IMS TM applications through the MVS Cross System Coupling Facility (XCF).

The IMS bridge is supplied as part of IBM WebSphere MQ for z/OS.


The IMS bridge

z/Series Sysplex

z/Series

IMSapplication

IMS/ESA

OTMAGU

IOPCB

ISRTIOPCB

Network

WebSphere MQ for z/Series

OTMAclient XCF




Uempty
Instructor notes:
Purpose — Review the IMS bridge.

Details — Applications in IBM WebSphere MQ place messages on queues in the usual manner. The message would be made up of IMS transaction data and may have an IMS header. The header is optional, since the queue manager can be permitted to make some assumptions about the data in the message.

A unique storage class associated with the queue identifies it as an OTMA queue, used to send messages to the WebSphere MQ-IMS bridge.

Transition statement — In addition to IMS, CICS is an important partner for IBM WebSphere MQ in the z/OS environment.



Instructor Guide

Figure 8-3. The CICS DPL bridge WM101 / VM1011.0

Notes:

The WebSphere MQ CICS DPL (distributed program link) bridge allows a CICS program to be invoked using the EXEC CICS LINK command. The program must conform to the DPL subset of the CICS API. The CICS DPL bridge allows applications that are not on CICS to communicate with CICS DPL programs without needing to change the CICS program to include WebSphere MQ API calls.

Like the IMS bridge, the CICS bridge is delivered as part of IBM WebSphere MQ for z/OS.



The CICS DPL bridge

MQGET…BROWSE

CICA/ESAbridge monitor

MQGET……

MQPUT

CICA/ESAbridge task

MQPUT

User program




Uempty
Instructor notes:
Purpose — Introduce the WebSphere MQ CICS bridge.

Details — The first implementation was for DPL support. The 3270 support is more recent and behaves differently, as the next chart indicates.

A brief look at the flow:

1. A message is put on a request queue by an application that is not running on CICS.

2. The CICS bridge monitor task constantly browses the queue, and when a message arrives, starts a new unit of work.

3. After normal authentication processing, the CICS DPL bridge task itself is started.

4. The bridge task MQGETs the incoming message.

5. The bridge task uses a COMMAREA to provide the data from the message when it issues an EXEC CICS LINK to invoke the program.

6. The DPL program passes any response using the same COMMAREA.

7. The bridge task reads the COMMAREA, builds a reply message, and puts it on the appropriate reply queue.

8. The bridge task ends.

Transition statement — Now look at the WebSphere MQ CICS 3270 bridge to see how it behaves.



Instructor Guide

Figure 8-4. The CICS 3270 bridge WM101 / VM1011.0

Notes:

The WebSphere MQ CICS 3270 bridge allows an application to run a 3270-based transaction without knowledge of the 3270 data stream. Data that are necessary to run the transaction are MQPUT on a queue by a program that is not a CICS program. From the CICS transaction perspective, it runs as though it has a real 3270 terminal. In reality, WebSphere MQ messages are being used to communicate.

It is important to note that, unlike traditional emulators, the bridge does not replace VTAM flows with WebSphere MQ messages. The program is dealing with the transaction rather than via an emulator.


WebSphere MQ server or client

The CICS 3270 bridge

Request message

Response message

z/Series


CICS/ESA

CICS bridgemonitor

CICS 3270 bridge task

MQ-CICSbridge

exit Usertrans-action

EXECCICSSTART

MQGET browse request

MQGET request

MQPUT response

1

2

3

4 5

67




Uempty
Instructor notes:
Purpose — Review the aspects of the WebSphere MQ CICS 3270 bridge.

Details — Instead of using an emulator approach, the message consists of a number of parts called vectors. Each vector corresponds to an EXEC CICS request. The vectors enable the application to use the actual data used by the transaction when talking to the CICS transaction.

Briefly looking at the flow:

1. The message (with a request to run a CICS transaction) is placed on a queue.

2. The CICS bridge monitor task starts a new unit of work.

3. The CICS bridge task is started after authentication.

4. WebSphere MQ CICS bridge exit removes the message from the queue, and changes task to run a user transaction.

5. Vectors in the message provide data to answer all terminal-related input EXEC CICS requests in the transaction.

6. Terminal-related output requests cause output vectors to be built.

7. The bridge exit takes the output vectors, builds a single WebSphere MQ reply message, and puts it on the reply queue.

8. The bridge task ends.

Additional information — A separate WebSphere MQ CICS Bridge User's Guide is supplied with the SupportPac (CICS SupportPac CA1E). It contains installation information, programming considerations, messages, and other information that may be required to use the bridge.

Transition statement — You next look at the SAP R/3 link.



Instructor Guide

Figure 8-5. The link for SAP R/3 WM101 / VM1011.0

Notes:

The WebSphere MQ link for SAP R/3 connects existing R/3 business applications with other applications, using IBM WebSphere MQ facilities. The WebSphere MQ link for SAP R/3 allows programs to be easily adapted and more flexible because all networking is transparent to the application.

WebSphere MQ acts as a transport mechanism to allow access to R/3 IDOCs from non-SAP R/3 environments. In addition, IBM WebSphere MQ can be used to connect two or more R/3 systems so they can take advantage of the messaging and queuing benefits.


The link for SAP R/3

WebSphere MQlink

Convertertool

WebSphere MQlink

Convertertool

IDOC

IDOC

Messagedata

Messagedata

Inbound

Outbound

Message Message

MessageMessage

Queue

Queue

SAP R/3

SAP R/3




Uempty
Instructor notes:
Purpose — Discuss the SAP R/3 link.

Details — IBM WebSphere MQ has been certified for the new SAP Cross-Application – ALE Message Handling Systems (CA-AMS). This certification means that there is guaranteed support in future releases of SAP.

Transition statement — The next topic is WebSphere MQ Everyplace.



Instructor Guide

Figure 8-6. WebSphere MQ Everyplace WM101 / VM1011.0

Notes:

IBM WebSphere MQ Everyplace is a toolkit that enables users to write IBM WebSphere MQ Everyplace applications, and to create an environment in which to run them.

The WebSphere MQ device is a computer running IBM WebSphere MQ Everyplace code without a channel manager. This means that a device is restricted to communication with only one other device or gateway at a time. IBM WebSphere MQ Everyplace devices can range from the small (such as a sensor), through larger devices (such as a telephone, personal data assistant, or notebook computer), up to desktop machines and workstations.

A gateway is a computer running the IBM WebSphere MQ Everyplace code with a WebSphere MQ Everyplace channel manager or WebSphere MQ Everyplace channel listener configured. This configuration offers all the capabilities of the device code, plus the ability to communicate with multiple device gateways concurrently. Gateways also provide the mechanism for exchanging messages between a WebSphere MQ Everyplace network and a WebSphere MQ network.


WebSphere MQ Everyplace

Gateway

Queuemanager

Devices




Uempty
Instructor notes:
Purpose — Introduce the IBM WebSphere MQ Everyplace toolkit.

Details —

Additional information — None.

Transition statement — The applications you have discussed so far have been typical request/reply applications, in which a program sends a message to IBM WebSphere MQ and expects to receive a response at some point. IBM WebSphere MQ also supports the publish/subscribe messaging model.



Instructor Guide

Figure 8-7. Publish/subscribe examples WM101 / VM1011.0

Notes:

Publish/subscribe is an asynchronous messaging paradigm in which senders (publishers) of messages are not programmed to send their messages to specific receivers (subscribers). Rather, published messages are characterized into classes, without knowledge of what (if any) subscribers there might be.

Publishers are loosely coupled to subscribers, and do not need to know of their existence. With the topic being the focus, publishers and subscribers are allowed to remain ignorant of system topology. Each can continue to operate normally regardless of the other.


Publish/subscribe examples

• Magazine publishing• Airline departure notification

– Notification boards might display (subscribe to)– All departures, departures at this terminal– Departures by this airline– Automated delay and cancelation notification using email notification and

automated outbound telephone call message notification• Weekly sale item valued customer notification




Uempty
Instructor notes:
Purpose — Define the publish/subscribe paradigm.

Details — The IBM WebSphere MQ publish/subscribe is new in version 7 of the IBM WebSphere Message Broker.

Additional information — Conversion tools are provided with IBM WebSphere V7 for conversion from previous WebSphere MQ publish/subscribe and IBM WebSphere Message Broker publish/subscribe.

Transition statement — Here are more details about publish/subscribe.



Instructor Guide

Figure 8-8. WebSphere MQ publish/subscribe WM101 / VM1011.0

Notes:

Publish/subscribe is a messaging interaction model. It defines an interaction in which each message can be delivered to multiple receivers. The actual model defines zero or more recipients, all receiving the same published message. Publish/subscribe works by the use of topics, which are also known as subjects. Potential receivers subscribe to a set of topics in which they are interested. These potential receivers are known as subscribers. Senders, or publishers, publish messages on a particular topic. When messages are published, a publish/subscribe broker delivered with IBM WebSphere MQ scans the subscription lists to see which subscribers are interested in the topic. WebSphere MQ republishes the message to each subscriber.

The model described in the figure can be implemented on many different transports, providing different classes of service for the messages. There is an implementation available within WebSphere MQ providing publish/subscribe on any type of supported messaging. WebSphere MQ also supports extended capabilities, such as subscribing based on message content as well as topic.


WebSphere MQ publish/subscribe

A

B

C

E

Publish/subscribeIBM WebSphere MQ (B)

= Application

(A)

= Subscriptionrequest (topic)

= Republish

(A,B)

D




Uempty
Instructor notes:
Purpose — Introduce IBM WebSphere MQ publish/subscribe.

Details — Publish/subscribe can be used in many WebSphere MQ environments. It is an alternative to typical request/reply messaging.

Additional information — WebSphere Message Broker extends the basic publish/subscribe capabilities that WebSphere MQ offers (to be discussed shortly).

Transition statement — There are two other products of interest that are part of the WebSphere MQ family.



Instructor Guide

Figure 8-9. WebSphere Business Integration Adapters WM101 / VM1011.0

Notes:

Because not all application environments support messaging, it is necessary to provide an alternative mechanism to allow non-messaging applications to interact with a messaging environment. This alternate mechanism is WebSphere Business Integration Adapters. As shown on the diagram, there are three main parts to the adapter:

1. The transport is the target message exchange mechanism for the adapter. The target is generally messaging, but the architecture of the adapters allows the target to be any appropriate transport.

2. The adapter framework is the heart of the adapter. It is common to all of the adapters available from IBM, which are listed on the next page. It provides all of the support required to process information associated with the target application environment. As the description suggests, this component provides functions that are common to all of the adapters, regardless of the target application.

3. The application-specific component is the part of the adapter that understands the application environment and how to interact with it. As the name suggests, this component is specific to each application environment.


Adapter

WebSphere Business Integration Adapters

• Transport– JMS-based message queuing– Other transports available

• Adapter framework– Common runtime infrastructure– Assures uniformity in administration

and behavior across the adapter family

• Application-specific component– Bidirectional connectivity with

application API or technology interface

Application

Adapter framework

Integrationbroker

Application-specific component

Transport layer

Transport interface

Generic services

Application interface functions

Applicationevent

notification

Businessobjecthandler

Base classfunctions




Uempty
There are many different WebSphere Business Integration Adapters. Each provides interaction with a specific target environment. There is a set of application adapters, designed to interact with particular, named applications. There is also a set of technology adapters. These adapters interact with specific technologies such as files, databases, web services, and so on.
For a current list of WebSphere Business Integration Adapters, see:www.ibm.com/software/integration/wbiadapters

Application adapters Technology adapters E-business adapters

• ACCORD • Adapter for email • Trading Partner Interchange

Trading Networks • Ariba • XML • Trading Partner Interchange Sol

• Centricity • WebSphere MQ • Trading Partner Interchange

On-Ramp

• Clarify CRM • WebSphere MQ

Integrator • Web Services

• eMatrix • WebSphere MQ

Workflow • J2CA or EJB Connection to

InterChange Server • ESRI • JText • iSoft Peer-to-Peer Agent

• i2 • JDBC (Java Database

Connectivity API) • i2 Active Data

Warehouse • SWIFT Mainframe adapters

• Indus Connect • FIX protocol • CICS • JD Edwards OneWorld • COM • IMS Transaction Manager • Manugistics • CORBA • IMS database manager • Maximo MEA • HTTP • Adapter for VSAM • MetaSolv Applications • Microsoft Exchange • DB2 databases

• mySAP.com • Healthcare Data

Protocols • ADABAS

• Oracle Applications • Lotus Domino • Natural • PeopleSoft • iSeries • IDMS database

• Portal Intranet • SAP Exchange

Interface • QAD • Siebel e-business

Applications • WebSphere Commerce • NightFire Applications • Spirent Applications • Telcordia Applications • Retek



Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty

Figure 8-10. WebSphere Message Broker WM101 / VM1011.0

Notes:

WebSphere MQ is designed to reliably transport messages between applications. In doing so, the queue managers ignore the content of the messages that are being transported. This technique works well if the sending and receiving applications are aware of the requirements on the other side, particularly in terms of how the message data is represented. If the side does not know the requirements on the other side, some other component needs to broker the interaction between applications. The broker needs to provide content based routing, message transformation, and complex data handling. These capabilities are provided by the WebSphere Message Broker.

WebSphere Message Broker provides functions to enable messages to be broken down into their constituent parts (the message fields) and for messages to be routed and transformed.

WebSphere Message Broker supports the notion of message flows to control the processing of messages through the broker. A visual, declarative programming environment is provided to enable the construction, deployment, and debugging of these message flows.


WebSphere Message Broker

WebSphere Message Broker

Development components(message flows, message maps, others)

WebSphere MQ

Other adapters and transports

Databasemanagement

system

WebSphere MQ

Other adapters and transports

User name server



Instructor Guide

As mentioned earlier, WebSphere Message Broker also supports sophisticated publish/subscribe messaging. It provides a superset of the capabilities offered by IBM WebSphere MQ.

WebSphere Message Broker supports message queue-based interactions, but also supports other transports, including HTTP (for web services support), Java Message Service support, and direct IP connections, along with many others. WebSphere Message Broker also provides native support for message mapping between source and target applications. It also provides the capability of interacting directly with other vendor application environments.




Uempty
Instructor notes:
Purpose —

Details —

Additional information — WebSphere Message Broker is just one of the products in the WebSphere Enterprise Service Bus suite. You might also want to discuss WebSphere Enterprise Service Bus, WebSphere Transformation Extender, or other ESB products.




Instructor Guide


Notes:

This unit describes some interesting points to consider if you plan to implement WebSphere MQ. It is easier to enable the assured once-and-once-only delivery provided by WebSphere MQ, which aids data delivery throughout the enterprise, if you use the links, bridges, and complementary products that you have seen throughout this course.


Unit summary

Having completed this unit, you should be able to:• List the various links and bridges used with WebSphere MQ• List other functions and products that make up the WebSphere MQ

family• Describe the publish/subscribe functionality




Uempty
Instructor notes:
Purpose — Summarize the unit and the course.

Details — In summarizing this unit, point out the major benefits of IBM WebSphere MQ as the vehicle to ensure that mission-critical data is delivered to the many different areas of an enterprise.

This one-day overview has covered only a small portion of IBM WebSphere MQ functions and facilities, but it should leave the students with a fairly complete high-level view of the product.

Additional information — Thank the students for the time they have taken from their jobs to attend this course.




Instructor Guide


Notes:

1. The IMS bridge is:

a. A Java client.b. An OTMA client.c. An MQI client.

2. True or False: The CICS DPL bridge enables a transaction to run as if it has a real 3270 terminal.

3. True or False: WebSphere MQ is a major transport mechanism of the Enterprise Server Bus.

4. True or False: Publish applications need to be aware of all subscribers interested in receiving published information.



1. The IMS bridge is: a. A Java client.b. An OTMA client.c. An MQI client.







Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide


Notes:

1. The IMS bridge is:

a. A Java client.b. An OTMA client.c. An MQI client.

Answer: b.


Answer: False. The CICS 3270 bridge enables a transaction to run as if it has a real 3270 terminal.


Answer: True.


Checkpoint answers

1. The IMS bridge is: a. A Java client.b. An OTMA client.c. An MQI client.Answer: b.

2. True or False: The CICS DPL bridge enables a transaction to run as if it has a real 3270 terminal. Answer: False.

3. True or False: WebSphere MQ is a major transport mechanism of the Enterprise Server Bus.Answer: True.

4. True or False: Publish applications need to be aware of all subscribers interested in receiving published informationAnswer: False.




Uempty
Answer: False. Publishers do not need to be aware of all subscribers.



Instructor Guide

Instructor notes:

Purpose —

Details —





Instructor GuideV5.4

Uempty
Unit 9. Course summary
Estimated time

00:15


This unit summarizes the course.



• Explain how the course met its learning objectives

• Submit your evaluation of the class

• Identify other WebSphere Education courses related to this topic

• Access the WebSphere Education website

• Locate appropriate resources for further study


© Copyright IBM Corp. 2011 Unit 9. Course summary 9-1

Instructor Guide


Notes:


Unit objectives

After completing this unit, you should be able to:• Explain how the course met its learning objectives• Submit your evaluation of the class• Identify other WebSphere Education courses related to this topic• Access the WebSphere Education website• Locate appropriate resources for further study




Uempty
Instructor notes:
Purpose — List the course summary objectives.

Details —





Instructor Guide

Figure 9-2. Course learning objectives WM101 / VM1011.0

Notes:


Course learning objectives

Having completed this course, you should be able to:• Compare IBM WebSphere MQ with other forms of program-to-program

communication• Identify the impact WebSphere MQ can have on application design• Describe the basic components and structure of IBM WebSphere MQ• Describe the function of each of the calls in the Message Queue Interface• Describe the tasks that must be performed to manage a queue manager and its

connections with:– Other queue managers– WebSphere MQ client applications

• Describe the transactional support within the IBM WebSphere MQ product• Describe the features of IBM WebSphere MQ that contribute to system security• Explain how IBM WebSphere MQ can be used as part of the communications

infrastructure to:– Connect application environments, such as the World Wide Web, enterprise

transaction systems, and database systems– Manage the dissemination of publisher information to appropriate subscribers




Uempty
Instructor notes:
Purpose — List the course learning objectives.

Details —





Instructor Guide

Figure 9-3. Class evaluation WM101 / VM1011.0

Notes:


Class evaluation

• Your comments about this class are very useful to WebSphere Education

• Feedback on the site, curriculum, and instructor tell us what was good about the class and what can be improved

• Please take the time to fill out the course evaluation on the IBM Training web site:

http://www.ibm.com/training/osart




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 9-4. To learn more on this subject WM101 / VM1011.0

Notes:


To learn more on this subject

• WebSphere Education web site:www.ibm.com/websphere/education

• Training paths:www.ibm.com/software/websphere/education/paths/

– Identify the next courses in this sequence• Resource Guide

– Contains information on many useful sources of information• Many of these sources are free

– See handout in your class materials, or download a copywww.ibm.com/developerworks/wikis/display/WEinstructors/WebSphere+Resource+Guide

• E-mail address for more information:[email protected]

• Education CD and documents in your class materials




Uempty
Instructor notes:
Purpose — Provide resources for further learning.

Details —





Instructor Guide

Figure 9-5. References WM101 / VM1011.0

Notes:


References

• All WebSphere MQ documents and reference materials are availableonline at the WebSphere MQ product family home page:http://www.ibm.com/software/integration/wmq/library

• IBM WebSphere MQ Quick Tour:http://www.ibm.com/software/integration/wmq/quicktour




Uempty
Instructor notes:
Purpose — Provide references for the information in this course.

Details —





Instructor Guide


Notes:


Unit summary

Having completed this unit, you should be able to:• Explain how the course met its learning objectives• Submit your evaluation of the class• Identify other WebSphere Education courses related to this topic• Access the WebSphere Education website• Locate appropriate resources for further study




Uempty
Instructor notes:
Purpose — Summarize the course summary unit.

Details —





Instructor Guide




AP
Appendix X-. List of abbreviations
ACL Access control list

API Application programming interface

ASCII American Standard Code for Information Interchange

CICS Customer Information Control System

DPL Distributed program link

EJB Enterprise Java Bean

ESB Enterprise service bus

GUI Graphical user interface

IBM International Business Machines Corporation

IMS Information Management System

IP Internet Protocol

ISC intersystem communication

ISPF Interactive System Productivity Facility

IT Information Technology

HTTP Hypertext transport protocol

J2EE Java 2 Enterprise Edition

J2SE Java 2 Platform, Standard Edition

JAAS Java Authentication and Authorization Service

JAF JavaBeans Activation Framework

JAXP Java API for XML Parsing

JDBC Java Database Connectivity API

JMS Java message service

JTA Java Transaction API

MQI Message queue interface

MVS Multiple Virtual Systems

OAM Object authority manager

RACF Resource Access Control Facility

SOA service-oriented architecture

SSL Secure socket layer

TCP Transmission Control Protocol


© Copyright IBM Corp. 2011 Appendix X-. List of abbreviations X--1

Instructor Guide

VSAM Virtual Storage Access Method


X--2 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

V5.4.0.3

backpg
Back page

Date post:	03-Dec-2015
Category:	Documents
Upload:	cece62
View:	14 times
Download:	0 times

WM1011-VM1011INST

Documents