Copyright IBM Corporation 2009,2011. All rights reserved. From Zero to z/hero IBM SWG Wildfire Workshops WebSphere MQ V7 for z/os Lab Version V2.0.3- Wildfire 2011 October 2014 Change History Vers. Datum Änderung 2.0.3 2.0.2 MQ V7.1 als Trägersystem - veränderte IP Adressen Typos 14.Okt.2013 10.Okt.2011 Wildfire-WebSphere WMQv7 Seite 1 von 47
Inhaltsverzeichnis Überblick... 3 Was für Sie vorbereitet wurde... 4 Allgemeine Anleitung TSO Logon und Einrichten von Mehrfach-Screens... 6 1Übung 1: Publish/Subscribe.... 11 1. Definition von TOPIC Objekten mittels MQSC Commands... 12 2. Pub/Sub Administration mit MQ Explorer... 16 3. Erste Schritte mit den MQ Explorer Pub/Sub Tools... 21 4. Administrierte Subscriptions (1)... 25 5. Publish/Subscribe mit Sample Batch Programmen... 26 6. Administrierte Subscriptions (2)... 28 Übung 2: Neue V7 Client Features... 29 1. Vorbereitende Maßnahmen... 29 2. Verbinden des Clients mit dem WMQ Host Queue Manager (Server).... 31 3. Asynchronous PUT... 32 4. Read-Ahead ( streamed MQGET )... 34 5. Besonderheiten bei Async PUT und Read-Ahead... 35 6. Die neue MQ Client ini File... 38 7. Verifizieren der MAXINST* Client Kanal Attribute... 40 Übung 3: Asynchronous Consume Funktion... 41 1. Analyse des Programms mqcb.c... 41 2. Ausführen des Callback Beispiel Programms MQCB... 44 Seite 2 von 47
Überblick Im Rahmen der hier angebotenen Übungen werden Sie die Gelegenheit haben, einige der neuen und erweiterten Funktionen von WebSphere MQ auf z/os V7 zu kennen zu lernen. Die Instruktionen bieten Ihnen Anleitung: zur Definition der Objekte, die zur Nutzung der Publish & Subscribe Funktion einzurichten sind, sowohl mit nativer MQSC Command Oberfläche in ISPF wie auch GUI-gestützt mit dem MQ Explorer; für einfache Publish & Subscribe Übungen; die neuen WMQ Client Features zu nutzen und ihre besonderen Wert zu erkennen: Asynchrones MQPUT Read-Ahead Limitierung zulässiger Sessions pro Client die neue Call-Back Funktion einzusetzen Platzhalter-Sonderzeichen (#, $, %) Zur Unterscheidung der Ressourcen der einzelnen Übungsteilnehmer sind deren Namen (Userids, Dataset/ Filenamen etc.) suffiziert, wobei bis zu drei PlatzhalterSonderzeichen verwendet werden. Diese werden durchgehend in derselben Weise verwendet, und Sie werden sich leichter tun, wenn Sie die Zuordnung kennen und verstehen: # hat den Wert 1...4 und steht für die LPAR, auf der Sie arbeiten $ ist eine Team-Kennung, entweder 3 oder 4 % ist entweder A oder B, und bezeichnet den einzelnen User Seite 3 von 47
Was für Sie vorbereitet wurde auf dem z/os Host Je nach Anzahl der Workshop-Teilnehmer können Sie alleine oder in Zweier- Teams arbeiten. Zweier-Team bedeutet, dass Sie einen gemeinsamen z/os Queue Manager nutzen, aber individuelle TSO Ids erhalten. Die Workshop-Umgebung besteht aus 4 LPARs, auf denen je zwei Queue Manager laufen. Die folgenden Namen sind vergeben: LPAR SYS1 Queue Manager MQ13 TSO User IDs WBI13A WBI13B MQ14 WBI14A WBI14B SYS2 MQ23 WBI23A WBI23B MQ24 WBI24A WBI24B SYS3 MQ33 WBI33A WBI33B MQ34 WBI34A WBI34B SYS4 MQ43 WBI43A WBI43B MQ44 WBI44A WBI44B WebSphere MQ for z/os ist in der Version 7.1.0 installiert in MQM.V710.SCSQ* (Target Libs) bzw. /usr/lpp/mqm/v7r1m0 (HFS) Die Queue Manager gemäß obiger Tabelle sind fertig konfigureirt und startbereit. Zugang zu den ISPF WMQ Panels ist über die Option mq im ISPF Hauptmenü gegeben; Weiterhin werden für die Übungen SDSF für die Kontrolle der Job Ausführung und deren Outputs verwenden Option sd im ISPF Hauptmenü. Seite 4 von 47
auf Ihrer Windows Workstation Für jeden Übungsteilnehmer bzw. jedes Teilnemerteam wurde eine Windows XP- Umgebung in Form eines VMWare Images vorbereitet, auf dem folgende Komponenten vorinstalliert sind: WebSphere MQ for Windows ist installiert im Verzeichnis c:\program Files\IBM\WebSphere MQ Sie werden davon auf jeden Fall die Client-Funktion verwenden und (optional) im Rahmen der distributed Pub/Sub Übungen einen Queue Manager auf Windows einrichten. Der WebSphere MQ Explorer ist installiert und startbar von einem Desktop Icon aus: Im Explorer sind die z/os Queue Manager für den administrativen Zugriff vorkonfiguriert ein lokaler Windows-Queue Manager wird im Rahmen der Übungen erstellt, wobei dessen Konfiguration durch vorgefertigte Scripts unterstützt wird. Für den Host-Zugang ist IBM Personal Communications installiert, und entsprechende vorkonfigurierte 3270-Sessions, mit denen auf das z/os System des Böblinger ztecs zugegriffen werden kann. Ihre Vorbereitung besteht darin, dass Sie das Icon für Ihr System (SYS1...4) vom Desktop- Ordner 3270 Links auf den Desktop ziehen, damit Sie in der Folge direkt und einfach darauf zugreifen können. Vorgaben und Hilfsmittel für die durchzuführenden Übungen sind über die Desktop-Ordner labfiles und Tools verfügbar. Seite 5 von 47
Allgemeine Anleitung TSO Logon und Einrichten von Mehrfach-Screens Sie werden sich das Arbeiten im TSO sehr erleichtern, wenn Sie der hier gegebenen Anleitung folgen und sich für die Dauer der Übungen in Ihrer TSO Session eine Split-Screen-Konfiguration aufbauen, so dass sie einfach und schnell zwischen den verschiedenen Stellen, an denen Sie aktiv werden sollen, umschalten können. Verbinden mit dem System z des TMCC Böblingen Durch Doppelklick auf das entsprechende Wildfire-SYS# (#=1...4) Symbol auf Ihrem Windows Desktop starten Sie die 3270 Session mit dem Host Der VTAM Usstab Screen stellt sich wie folgt dar (Darstellung für SYS2): geben Sie an der ursprünglichen Cursorposition, nach dem Pfeil, welches das einzige Eingabefeld ist, TSO WBI#$% ein, - wobei Sie die '#$%' Zeichenfolge mit Ihrer ID-Kennung ersetzen, wie oben für die Userid WBI24A dargestellt (die Eingabe ist nicht casesensitive) und schließen mit der 3270-Eingabetaste, welches die Strg/Ctrl Taste Ihrer Workstation ist, ab. Dies wird Sie zum TSO Logon Screen bringen. Seite 6 von 47
TSO Logon Im TSO Logon Screen geben Sie das Ihnen bekannt gegebene Passwort ein, und betätigen erneut die 3270-Eingabetaste Ihre TSO Session wird aufgebaut. wenn Sie die folgende Anzeige sehen, betätigen Sie nochmal die 3270- Eingabetaste (Strg/Ctrl) und im folgenden Panel geben Sie an der Eingabestelle (Process Option...) eine 2 eine und betätigen abermals die 3270-Eingabetaste (Strg/Ctrl) zweimal dies wird Sie zum SYSTEM MASTER APPLICATION MENU bringen. Seite 7 von 47
Herstellen der 3-splitted-Screens Anordnung 1. DSLIST (ISPF Option 3.4) für Edit und Job Submit Geben Sie im SYSTEM MASTER APPLICATION MENU als Option 3.4 ein (ohne Anführungszeichen)... und im nachfolgenden Data Set List Utility Panel wählen Sie als Dsname Level WBI#$%.WMQ* (wobei Sie anstelle von '#$%' Ihre User-Kennung angeben), wie hier für WBI24A dargestellt (Groß-/Kleinschreibung muss hier nicht beachtet werden): Im folgenden Panel können Sie auf Ihre Datasets zugreifen- wir gehen davon aus, dass Sie ab hier zurecht kommen.. 2. SDSF Screen für Job Output Kontrolle Platzieren Sie Im offenen (DSLIST) Screen den Cursor in der obersten Zeile (je nach Einstellung) und drücken Sie die F2 Taste für Split Screen. Ein neuer SYSTEM MASTER APPLICATION MENU Screen tut sich auf. Geben Sie hier als Option sd (für SDSF) ein (ohne Anführungszeichen, nicht case-sensitiv) Dies bringt Sie zum SDSF PRIMARY OPTION MENU Hier wählen Sie als Command Input st (für Status -wiederum ohne Anführungs-zeichen und nicht case-sensitiv)... und Sie werden die laufenden -und später die abgeschlossenenprozesse (Jobs), die Ihr Team betreffen, aufgelistet sehen Hinweis: es sollte nicht nötig sein, die SDSF Einstellungen zu verändern! Seite 8 von 47
3. Screen für WebSphere MQ ISPF Panels Platzieren Sie Im aktuellen SDSF Screen den Cursor in der COMMAND INPUT Zeile und geben Sie split new ein (wieder ohne Anführungszeichen) Ein neuer SYSTEM MASTER APPLICATION MENU Screen tut sich auf, der aber höchstwahrscheinlich weitgehend verdeckt erscheint. Platzieren Sie den Cursor in der untersten Bildschirmzeile und drücken Sie die F2 Taste. Dies wird diesen neuen Screen sichtbar machen. Geben Sie nun die Option mq ein dies bringt Sie zu einer installations-eigenen Auswahl, in der alle definierten Queue Manager aufgelistet sind. Platzieren Sie den Cursor in der ersten Spalte Ihres Queue Managers (entsprechend Ihrer Team/User-Kennung) und drücken Sie Enter. damit haben Sie die WMQ ISPF Panels aufgerufen, und die Zugriffsfelder sind schon für Ihren Queue Manager ausgefüllt. Seite 9 von 47
Nun haben Sie die drei Screens eingerichtet, zwischen denen Sie jederzeit durch Eingabe von swap # (mit #=1,2 oder 3) an der jeweiligen Command Input Stelle springen können. Es ist von Vorteil, wenn man sich genau an diese Vorgaben gehalten hat, und jederzeit klar ist: swap 1 bringt stets den Screen mit den JCL Vorgaben ==> CNTL-Screen swap 2 stets SDSF für Job Output Kontrolle, und ==> SDSF-Screen swap 3 Zugriff auf die WMQ ISPF Panels ==> MQ-Screen In den folgenden Übungsanleitungen werden die entsprechenden Screens dann entsprechend benannt! Seite 10 von 47
Übung 1: Publish/Subscribe Worum es in diesem Übungsteil geht Erste Schritte mit MQ Publish & Subscribe. Diese Übung wird zunächst die Administration der Pub/Sub Elemente behandeln, wobei Sie WMQ Objekte per Batch (CSQUTIL) und mit dem MQ Explorer erstellen. Sie werden einen Topic Tree erstellen, wobei für Zweier-Teams die Möglichkeit besteht, dass jedes Teammitglied die Übungen für sich durchführt. Das Ergebnis des ersten Teils ist eine Topic-Struktur, die in späteren Übungen verwendet wird. Die ersten Pub/Sub Vorgänge werden Sie mit den Test Publication und Test Subscription Funktionen des MQ Explorers starten. Die zu erstellende TOPIC STRING Struktur in der folgenden Grafik dargestellt. Seite 11 von 47
1. Definition von TOPIC Objekten mittels MQSC Commands Wir benutzen hierzu die Command Funktion der WMQ ISPF Panels- welche im Hintergrund die CSQUTIL Command Funktion anstößt. 1.1. Aktivieren Sie den SDSF-Screen ( swap 2 ) Ihrer TSO-Session und starten Sie den Team-Queue Manager durch die folgende Eingabe in der SDSF Command Input Zeile (wobei Sie die Sonderzeichen entsprechend Ihrer Team-Kennung ersetzen- die Eingabe ist nicht case-sensitive) /+MQ#$ START QMGR PARM( MQ#$ZPRM) Der folgende Screenshot-Auszug zeigt die korrekte Eingabe für Team 24: 1.2. Wenn nach kurzer Zeit die beiden MQ-Adressräume in der SDSF Statusanzeige als aktive Prozesse erscheinen, dürfen Sie davon ausgehen, dass der QMgr erfolgreich gestartet wurde. Wer misstrauisch ist, kann im System Log (SDSF Command-Eingabe log ) nach den folgenden Messages für den entsprechenden QMgr suchen :-) CSQY022I +MQ24 QUEUE MANAGER INITIALIZATION COMPLETE CSQ9022I +MQ24 CSQYASCP 'START QMGR' NORMAL COMPLETION. +CSQX022I +MQ24 CSQXSUPR Channel initiator initialization complete 1.3. Wechseln Sie zum MQ-Screen ( swap 3 ), wählen Sie (sofern nicht bereits geschehen) Ihren Queue Manager aus und geben Sie im Action Feld die 8 zum Aufruf der Command-Eingabe ein: 1.4. Geben Sie den folgenden DEFINE Command in dem sich öffnenden Eingabeschirm ein, wobei zu berücksichtigen ist: die Command-Schlüsselwörter (DEFINE, TOPIC, QUEUE etc.) sind nicht casesensitive hingegen sind die ObjektNAMEN- in diesem Fall der Name des Topics und der String- case-sensitive Die Fortsetzung einer Command-Eingaben in der nächsten Zeile ist durch ein + (Plus)Zeichen am Zeilenende anzuzeigen Seite 12 von 47
Darstellung mit Platzhalter <uid> für Ihre tatsächliche UserId: DEFINE TOPIC(<uid>.SPORT) TOPICSTR('<uid>/sport') Beispiel-Darstellung der realen Eingabe für User 24A: 1.5. Schließen Sie die Command-Eingabe mit F3=End ab. Der Command wird batch-mäßig ausgeführt und der Ausgang davon als AusgabeJoblog angezeigt. Bei korrekter Eingabe wird der Ergebnis-Screen diese Nachrichten enthalten (dargestellt für User 24A): DEF topic(wbi24a.sport) topicstr('wbi24a/sport') CSQN205I COUNT= 2, RETURN=00000000, REASON=00000000 CSQ9022I +MQ24 CSQMATOP ' DEF TOPIC' NORMAL COMPLETION. CSQU058I 1 commands issued and responses received, 0 failed. Wie Sie wahrscheinlich wissen, ist die letzte der hier dargestellten Nachrichten mit der 0 failed Angabe in Verbindung mit CSQUTIL Command-Ausführung besonders wichtig. 1.6. Wiederholen Sie die Command-Eingabe für weitere Topics gemäß nachfolgender Angabe (bitte sorgfältig sein mit den Namen): Hinweise: - der jeweils zuletzt eingegebene Command bleibt erhalten und wird bei Neuaufruf der Command-Funktion wieder angezeigt; dadurch bleibt einiges an Tipperei erspart. - nutzen Sie die ISPF Repeat Funktion DEF TOPIC(<uid>.FINANCE) TOPICSTR('<uid>/finance') DEF TOPIC(<uid>.SPORT.BASKETBALL) + TOPICSTR('<uid>/sport/basketball') Wir erwarten, dass diese Definitionen sauber angelegt werden. 1.7. Als Nächstes versuchen Sie, ein Topic gemäß dieser Angabe zu erstellen: DEF TOPIC(<uid>.FINANCE) TOPICSTR('<uid>/money') Wir erwarten, dass dieser Versuch fehlschlägt, mit folgendem Hinweis: CSQM095I +MQ24 CSQMATOP TOPIC(WBI24A.FINANCE) ALREADY EXISTS ==> der TOPIC Objektname muss also eindeutig sein! Seite 13 von 47
1.8. Als Nächstes versuchen Sie es mit folgender Topic-Definition: DEF TOPIC(<uid>.MONEY) TOPICSTR('<uid>/finance') auch dieser Versuch geht schief, mit dem Hinweis: CSQM095I +MQ24 CSQMATOP TOPICSTR(WBI24A/finance) ALREADY EXISTS ==> auch der TOPIC String muss eindeutig sein- was nicht überrascht... 1.9. Geben Sie als nächstes den Command DISPLAY TOPIC(*) ein die Ergebnisliste wird wie folgt aussehen beginnend mit einigen System-Topics; die von Ihnen definierten folgen danach (Darstellung für MQ24): DISPLAY TOPIC(*) CSQN205I COUNT= 10, RETURN=00000000, REASON=00000000 CSQM438I +MQ24 TOPIC(SYSTEM.BASE.TOPIC) TYPE(LOCAL) QSGDISP(QMGR) TOPIC(SYSTEM.BROKER.ADMIN.STREAM) TYPE(LOCAL) QSGDISP(QMGR) CSQM438I +MQ24 TOPIC(SYSTEM.BROKER.DEFAULT.STREAM) TYPE(LOCAL) QSGDISP(QMGR) CSQM438I +MQ24 TOPIC(SYSTEM.BROKER.DEFAULT.SUBPOINT)YPE(LOCAL). 1.10. Nächste Command-Eingabe: DISPLAY TPSTATUS(*) wir erwarten die folgende Nachricht als Ergebnis : CSQM297I +MQ24 CSQMDRTS NO TPSTATUS FOUND MATCHING REQUEST CRITERIA nicht etwa, weil es keinen Status gäbe, sondern weil das Sternchen '*' nicht die generische ( Wildcard ) Angabe von Topic Strings ist. 1.11. Probieren Sie's mit: DISPLAY TPSTATUS('#') da sollte jetzt eine valide Antwort zurückkommen, beginnend mit (für MQ24): CSQM443I +MQ24 TPSTATUS( WBI24A/finance ) TYPE(TOPIC) DEFPRESP(SYNC) DEFPSIST(NO) DEFPRTY(0) DURSUB(YES) PUB(ENABLED) SUB(ENABLED) ADMIN(WBI24A.FINANCE) MDURMDL(SYSTEM.DURABLE.MODEL.QUEUE) MNDURMDL(SYSTEM.NDURABLE.MODEL.QUEUE) NPMSGDLV(ALLAVAIL) PMSGDLV(ALLDUR) Seite 14 von 47
1.12. Manipulation der bestehenden FINANCE und SPORT Topics Das FINANCE -Topic soll sowohl für Publish als auch für Subscribe gesperrt werden; gegen das SPORT -Topic soll kein Publish erlaubt sein. dies erreichen wir durch die Eingabe folgender Commands: ALTER TOPIC(<uid>.FINANCE) PUB(DISABLED) SUB(DISABLED) ALTER TOPIC(<uid>.SPORT) PUB(DISABLED) Als Hilfestellung hier noch einmal der Screenshot für WBI24A: Führen Sie diese Commands aus; wir erwarten NORMAL COMPLETION für beide. 1.13. Überprüfen Sie abschließen die aktiven Definitionen des Topics <uid.finance> mittels des Commands DISPLAY TOPIC(<uid>.FINANCE) all im Ergebnis sollte der DISABLED Status für PUB und SUB sichtbar sein: CSQM438I +MQ24 TOPIC(WBI24A.FINANCE) TYPE(LOCAL) QSGDISP(QMGR) CLUSTER( ) TOPICSTR( WBI24A/finance ) DEFPRTY(ASPARENT ) DEFPSIST(ASPARENT) DURSUB(ASPARENT) NPMSGDLV(ASPARENT) PMSGDLV(ASPARENT) MDURMDL( ) MNDURMDL( ) PUB(DISABLED) SUB(DISABLED) PUBSCOPE(ASPARENT) SUBSCOPE(ASPARENT) PROXYSUB(FIRSTUSE) WILDCARD(PASSTHRU) DESCR( ) DEFPRESP(ASPARENT)... 1.14. Minimieren Sie das 3270 Fenster (nicht schließen oder logoff machen!). Seite 15 von 47
2. Pub/Sub Administration mit MQ Explorer 2.1. Starten des MQ Explorers und Connect zum z/os Queue Manager 2.1.1. Starten Sie den MQ Explorer durch Doppelklick auf das entsprechende Icon Ihres Windows Desktops Hinweis: Es sind alle z/os Queue Manager vordefiniert, jedoch sind alle hidden (versteckt). 2.1.2. Machen Sie Ihren Queue Manager sichtbar: durch Rechts-Klick auf Queue Manager, dann Klick auf Show/Hide Queue Manager 2.1.3. Wählen Sie in der danach angezeigten Liste Ihren z/os Queue Manager durch einfaches Anklicken der entsprechenden Zeile aus, und klicken Sie danach auf den Show Button (wie hier gezeigt für MQ24): 2.1.4. Wenn der Eintrag für Ihren Queue Manager in der oberen Liste der Shown Queue Managers erscheint, klicken Sie den Close Button und kehren so zur Explorer-Grundeinstellung zurück, wo Ihr Queue Manager nun ( hopefully ) im der Navigator-View aufgelistet ist 2.1.5. Rechts-Klicken Sie nun den Queue Manager Eintrag und Starten Sie die bereits definierte Verbindung durch Klicken auf die Connect-Option Wir erwarten, dass Verbindungsaufbau klappt, und dies durch die entsprechende Verfärbung des Icons vor dem QMgr-Namen angezeigt wird. Evtl. kommt beim ersten Verbindungsaufbau eine Warnung, die auf eine different QMgr ID hinweist - klicken Sie auf Yes, um die neue Verbindung zu akzeptieren. Seite 16 von 47
2.2. Darstellen eines TOPIC Objekts und seiner Eigenschaften 2.2.1. Öffnen Sie den TOPIC Ordner Ihres z/os Queue Managers, wodurch die definierten Topic Objekte angezeigt werden. Schalten Sie, sofern aktiv, die Anzeige der SYSTEM Objekte aus über das Show System Objects Icon rechts oben im Explorer Content View aus, so dass nur Ihre zuvor definierten Objekte dargestellt werden beachten Sie besonders die angezeigten Topic Strings, sowie die Publish und Subscribe Enable/Disable Anzeigen. Die Anzeige sollte so aussehen:xxx 2.2.2. Stellen Sie die Eigenschaften des <uid>.sport Topics durch Doppelklicken des entsprechenden Objektes dar. beachten Sie die verschiedenen Eigenschaften ( properties ) des Objekts. schauen Sie sich die verfügbaren Optionen der Properties mit Pull-down Attributauswahl an. Verlassen Sie die Properties Darstellung mit Cancel (damit nicht versehentlich irgendwelche Änderungen aktiviert werden). 2.3. Definieren eines weiteren Topics 2.3.1. Rechts-Klick auf Topics im Navigator View, dann New > Topic 2.3.2. Geben Sie dem neuen Topic den Namen <uid>.money und vergeben Sie den folgenden -etwas länglichen- Topic String (mit Ihrer TSO UserId als Top Level Qualifier) <uid>/finance/cash/gettingit/frombanks 2.3.3. Optional dürfen Sie im Description Feld noch eine Beschreibung eintragen, alles andere as default, dann Finish. Seite 17 von 47
2.4. Anzeige des Topic Status 2.4.1. Wieder Rechts-Klick auf den Topic im Navigator-View, und diesmal Auswahl von Status. ==> im Topic Status View ist zunächst nur ein Eintrag (für Zweier-Teams zwei Einträge) mit Ihrer User-ID zu sehen. 2.4.2. Klicken Sie nun auf das + (Pluszeichen) links von Ihrem WBIxxx Eintrag ==> die nächste Ebene des Topic(string) Hierarchie öffnet sich, mit den Einträgen für finance und sport. 2.4.3. Öffnen Sie die weiteren Ebenen des finance Zweiges, bis zur untersten Stufe, an der kein weiteres Pluszeichen mehr erscheint. Wir erwarten hier die folgende Anzeige: Beachten Sie, dass die Zwischen-Ebenen (.../cash/gettingit/..) mit angelegt wurden, und dass diese ihre Eigenschaften vom Parent-Topic finance geerbt haben. Für diese Ebenen gibt es kein TOPIC Objekt, und somit können die Attribute dieser Ebenen nicht eigenständig verändert werden 2.4.4. Verlassen Sie die Topic Status Ansicht mit Close. 2.5. Anlegen weiterer Nutz-Topics mittels MQ Explorer 2.5.1. Legen Sie mit Hilfe des MQ Explorers die folgenden drei neuen Topic Definitionen an, mit Namen/Eigenschaften gemäß folgender Tabelle (<uid> steht für Ihre TSO UserID, stets groß geschrieben). TOPIC OBJECT TOPIC STRING Publish <uid>.sport.football <uid>/sport/football Inhibited <uid>.sport.football.results <uid>/sport/football/results Inhibited <uid>.sport.football.results.hursley <uid>/sport/football/results/hursley Allowed Akzeptieren Sie für alle anderen Properties (außer Publish ) die Defaults. Seite 18 von 47
2.5.2. Die TOPIC Anzeige im Explorer sollte danach wie folgt aussehen (dargestellt für <uid>=wbi24): 2.5.3. Zeigen Sie noch einmal den Topic Status an, und brechen Sie die Ebenen des sport Zweigs bis ganz unten auch (+ Pluszeichen!) Beachten Sie, dass für den Topic String <uid>/sport/football/results/hursley Publish erlaubt ist, für die Ebenen darüber nicht! 2.6. Vervollständigen des Topic Trees per Batch Job 2.6.1. Kehren Sie zurück zur (hoffentlich noch aktiven) 3270 TSO Session, - schalten Sie dort mit swap 1 zur Edit/JCL-Session, - und öffnen Sie das Member WBI#$%.WMQV7.CNTL(DEFTOPIC) im EditModus. Dieses Member enthält weitere DEFINE TOPIC Commands, mit denen der eingangs vorgestellte Topic Tree komplettiert wird. 2.6.2. Ändern Sie mittels change all Funktion alle Instanzen des Platzhalters ++TEAM++ in den variablen teil Ihrer TSO ID, also z:. für WBI24A: Command ===> c ++TEAM++ 24A all und sichern Sie das Member danach. 2.6.3. Öffnen Sie das Member UTLCMD in derselben Library im Edit-Modus, und passen Sie, wiederum mittels change (all) Kommandos, die PlatzhalterStrings gemäß Text-Vorspann im Member, an: - change ++TEAM++ >> wie vor, Team-Nummer, einschl. A/B Suffix - change ++SYSN++ >> 1...4, Zehner-Kennung des Queue Managers - change ++QMGR++ >> voller Queue Manager Name - change ++INPUT++ >> DEFTOPIC, das Input Member von 2.6.2. 2.6.4. Submitten Sie den Job er sollte nur kurz laufen und mit RC=00 laufen. Seite 19 von 47
2.6.5. Prüfen Sie den Job Log in SDSF ( swap 2 ) - die wichtige Nachricht ist diese, am Ende des Joblogs: CSQU058I 7 commands issued and responses received, 0 failed 2.6.6. Überprüfen Sie das Ergebnis nun auch über die Anzeige der TOPIC Objekte im Explorer- diese sollte nun wie folgt aussehen: Damit ist die Topic-Hierarchie für die nachfolgenden Pub/Sub Übungen komplett! Seite 20 von 47
3. Erste Schritte mit den MQ Explorer Pub/Sub Tools 3.1. Aktivieren einer Test-Subscription 3.1.1. Starten Sie eine erste Subscription durch Rechts-Klick auf den Topics-Ordner Ihres Queue Managers im Explorer Navigator View, dann Auswahl von Test Subscription, wie hier für MQ24 dargestellt: 3.1.2. Geben Sie als Topic String an (mit Ihrer TSO-ID als <uid>): <uid>/sport/football/# und klicken Sie dann den Subscribe Button: Das Subscribe Fenster bleibt offen und der Unsubscribe Button wird aktiv. Dieses offene Fenster repräsentiert einen Prozess, der nun auf alle Ebenen ab./sport/football/ subskribiert ist und entsprechende (published) Messages in der Fläche unter Messages received anzeigen wird. 3.1.3. Minimieren (nicht schließen!) Sie dieses Subscribe Fenster. 3.2. Darstellen dieser aktiven Subscription im Topic Status 3.2.1. Öffnen Sie (einmal mehr) die Topic Status Anzeige (siehe 2.4.- falls nötig) 3.2.2. Öffnen Sie die komplette Struktur unterhalb von <uid>/sport/football und verschieben Sie die sichtbare Anzeigefläche im rechten Fenster so weit nach rechts, bis der Sub(scription) count sichtbar wird. (Screenshot nächste Seite) Seite 21 von 47
Topic Status mit Sub/Pub count Beachten Sie den Subscription Count: WBI24A/sport/football und alle Ebenen darunter haben eine Sub Count von 1. Schließen Sie das Topic Status Fenter wieder. 3.2.3. Wählen Sie in der TOPIC Anzeige des Explorers das Topic <uid>.sport.football aus, zeigen Sie mit Rechts-Klick die Optionen an und wählen Sie dann Topic Status > Subscribers. Auf diesem Weg erhalten wir Detailinformation über aktive Subscriber zu diesem Topic. Wir erwarten die folgende Anzeige, in welcher sich Ihre aktive TestSubscription niederschlägt: Haben Sie eine Idee, warum läuft die Subscription unter der UserID MQ24CHIN läuft? Sie können die Anzeige mit Close wieder schließen. Seite 22 von 47
3.3. Aktivieren einer Test Publication 3.3.1. Wie zuvor die Test Subscription, aktivieren Sie nun eine Publication auf dasselbe Topic: durch Rechts-Klick auf den Eintrag <uid>.sport.football in der TOPCIS Liste, dann Test Publication auswählen. 3.3.2. Im nun offenen Publish Test Message Dialog als Topic String wiederum <uid>/sport/football/# eingeben. 3.3.3. Bevor Sie nun im Message Bereich einen Nachrichtentext eintippen, ordnen Sie die Fenster auf dem Desktop so an, dass das (bis dahin minimierte) Subscribe Fenster neben dem Publish Fenster sichtbar ist, z.b. so: 3.3.4. Tippen Sie nun im Message data Bereich des Publish Fensters einen Text ein. 3.3.5. Was geschieht? Vermutlich gar nichts der Messages received Bereich des Subscriber Fensters bleibt leer 3.3.6. Erklärung (vielleicht haben Sie es ja auch schon selbst erraten): das Topic <uid>/sport/football ist für Publications gesperrt - inhibited - weil im Übungsschritt 2.5.1. entsprechend angelegt. Da die Subscription sich aber auf alles unter.../sport/football bezieht, sollte bei entsprechend gestaltetem Publish -Topic String diese Hürde zu überwinden sein! 3.3.7. Erweitern Sie im Publish Fenster den Topic String um zwei Stufen nach.../football/news/hursley, geben Sie nochmal einen Text ein und lösen Sie nochmal Publish message aus. Seite 23 von 47
3.3.8. Tut sich jetzt mehr als zuvor? wir erwarten, dass die Nachricht diesmal ausgeliefert wird und sofort im Messages received Bereich des Subscriber Fensters erscheintentsprechend der folgenden Darstellung: 3.3.9. Tippen Sie auf der Publish -Seite eine weitere Nachricht ein. erscheint auch diese umgehend als Message received? (es sollte so sein!) Noch ein Hinweis: <uid>/sport/football/news/hursley ist ja nun ein Topic String, der noch gar nicht definiert war. Er wurde dynamisch angelegt und wird als temporär betrachtet. Wenn es keine aktiven Publisher und Subscribers dafür gibt, werden diese Topics bei Restart des Queue Managers gelöscht, sonst (per Deafult) nach 30 Minuten. 3.3.10. Wenn Sie möchten, können Sie noch ein paar weitere Publishs gegen zusätzliche Topic String Ebenen durchführen. 3.3.11. Versuchen Sie ein letztes Publish gegen den Topic String: <uid>/sport/football/rules/offside. Was geschieht? - Warum wird keine Nachricht ausgeliefert? Antwort: die dafür neu/dynamisch angelegte Ebene erbt ihre Attribute von <uid>/sport/football, und diese ist PUB-inhibited. 3.3.12. Schließen Sie die Fenster für Test Pub/Sub (und damit die entsprechenden Prozesse); öffnen Sie abschließend nochmal die Topic Status Anzeige und brechen Sie die Hierarchieebenen im.../sport Zweig auf. Sie werden die automatisch angelegten Stufen zu sehen bekommen. Seite 24 von 47
4. Administrierte Subscriptions (1) Als administered subscriptions werden Subscriptions bezeichnet, die per DEFINE SUB Command aktiviert werden- was über die verschiedenen Arten der Command-Eingabe (CSQUTIL, Explorer) möglich ist. Die so aktivierte Subscription sammelt Messages auf einer Queue, und irgendeine MQ Anwendung kann diese Messages von der entsprechenden Queue lesen, ohne Pub/Sub APIs zu verwenden. Für Administered Subscriptions vergibt man beim DEF SUB Command einen Namen, unter dem die Subscription in der Folge anzusprechen ist. 4.1. Aufsetzen einer admin. Subscription 4.1.1. Öffnen Sie in Ihrem TSO CNTL Screen ( swap 1 ) das Member WBI#$%.WMQV7.CNTL(DEFSUB) im Edit-Modus, welches die MQSC Commands zum Definieren einer Queue WBI#$%.FOOTBALL.Q und einer admin. Subscription mit dem Namen WBI#$%.FOOTBALL.SUB. 4.1.2. Ändern Sie den Platzhalter ++TEAM++ an allen Stellen per change (all) Command entsprechend Ihrer Team-ID. Sichern und schließen Sie das Member. 4.1.3. Öffnen Sie das Member UTLCMD in derselben Library im Edit-Modus, und ändern Sie in der letzten Zeile den Input Member Namen nach DEFSUBentsprechend dem eben gerade aufbereiteten Member. 4.1.4. Submitten Sie den Job in UTLCMD Er sollte schnell durchlaufen und mit CC=0 enden. 4.1.5. Kontrollieren Sie den Job Output im SDSF ( swap 2 ) Die Message, die wir am Ende des Outputs sehen möchten, ist diese: CSQU058I 4.2. 2 commands issued and responses received, 0 failed Display der aktiven Subscription 4.2.1. Wechseln Sie zum MQ-Screen ( swap 3 ), rufen Sie erneut die CommandFunktion auf und geben Sie als Command ein: DISPLAY SUB(<uid>.FOOTBALL.SUB) all wobei Sie <uid> mit Ihrer TSO Userid ersetzen. 4.2.2. Wir erwarten einen Output wie folgt (Darstellung für User WBI24A): SUB( WBI24A.FOOTBALL.SUB ) SUBID(C3E2D8D4D4D8F2F44040404040404040C68F31E4ADCA0E03) DURABLE(YES) SUBTYPE(ADMIN) TOPICSTR( WBI24A/sport/football/# ) DEST(WBI24A.FOOTBALL.Q) DESTQMGR( ) Damit ist die Subscription aktiv und entsprechend publizierte Messages werden auf diese lokale Queue ausgeliefert- wir werden später darauf zurück kommen! Seite 25 von 47
5. Publish/Subscribe mit Sample Batch Programmen 5.1. Starten Sie im Explorer eine neue Test-Subscription (Vorgehen siehe 3.1.) mit dem Topic String: <uid>/sport/# (<uid> steht natürlich wieder für Ihre TSO Id; vergessen Sie nicht, den Subscribe Button zu klicken). 5.2. Ausführen der Pub/Sub Batch Programme 5.2.1. Member WBI#$%.WMQV7.CNTL(JCLPUB) enthält die JCL zum Starten des Publish-Programms (CSQ4BCP1). Editieren Sie das Member und führen Sie die change (all) Commands durch zum Ersetzen der ++...++ Platzhalter, wie in der vorigen Übung (siehe 2.6.3.) unter SYSIN DD * sind die zu publizierenden Nachrichten anzugeben; Sie können die beiden Pub_Message... Nachrichten stehen lassen, oder auch eigene Texte eingeben Sichern und schließen Sie das Member. 5.2.2. Member WBI#$%.WMQV7.CNTL(JCLSUB) enthält die JCL zum Starten des Subscriber-Programms (CSQ4BCP2). Führen Sie auch hierin sorgfältig alle change (all) Commands durch zum Ersetzen der ++...++ Platzhalter durch. Sichern und schließen Sie auch dieses Member. 5.2.3. Submitten Sie nun erst den JCLSUB Job, dann- unmittelbar danach- JCLPUB. wenn die JCL sauber ist (was sie nach dem vorherigen Schritt sein sollte), kann man durch Eingabe von sub (ohne Hochkomma) in der Memberliste den entsprechenden Job auslösen. die Reihenfolge (erst -SUB, dann -PUB) ist wichtig, denn wenn publiziert wird, bevor die Subscription aktiv ist, gehen die Messages ins Leere der Publish-Job wird sehr kurz laufen; das Subscriber-Programm wartet 30 Sekunden auf (weitere) Messages, dann beendet es sich automatisch. 5.2.4. Wechseln Sie zum SDSF-Screen ( swap 2 ) und überprüfen Sie den Job Output der beiden Jobs. Seite 26 von 47
Sofern beide Jobs sauber gelaufen sind, ist nur der JCLSUB Output wirklich interessant. Hier erwarten wir, die im JCLSUB Member hinterlegten Messagetexte zu sehen: Sample CSQ4BCP2 start Calling MQGET : 30 seconds wait time message <Pub_Message_1> Calling MQGET : 30 seconds wait time message <Pub_Message_2> Calling MQGET : 30 seconds wait time no more messages Sample CSQ4BCP2 end 5.2.5. Die gleichen Messages sollten auch an die MQ Explorer Test Subscription ausgeliefert worden sein- prüfen Sie das nach: Beenden Sie anschließend die Test Subscription. Seite 27 von 47
6. Administrierte Subscriptions (2) 6.1. Abgreifen von Messages der admin.subscription 6.1.1. Wählen Sie in der Subscription Liste des Explorers die Subscription <uid>.football.sub aus- dies ist die zuvor per Batch Job angelegte admin.subscription. Rechts-Klick > Status 6.1.2. Ermitteln Sie in der Statusanzeige die Anzahl ausgelieferter Messages (message count) Hier erwarten wir, die Anzahl der Messages zu sehen, die Sie zuvor mittels JCLPUB ausgelöst haben. 6.1.3. Schließen Sie die Status Anzeige wieder. 6.1.4. Stellen Sie jetzt die Messages auf der Queue (<uid>.football.q) mittels der Browse Message Funktion des Explorers dar 6.1.5. Wählen Sie eine der Messages durch Doppelklick aus, und klicken Sie im Message - Properties Fenster auf Named Properties. Wir erwarten folgendes: der Topic String, mit dem die Message publiziert wurde, ist als Wert der Property mqps.top Teil der jeweiligen Message. Seite 28 von 47
- Übung 2: Neue V7 Client Features Worum es in diesem Übungsteil geht In dieser Übung erhalten Sie Gelegenheit, einige der mit WMQ V7 neu eingeführten Client Features praktisch zu verwenden und somit ihren (potenziellen) Nutzen direkt zu erkennen. Sie werden: - die Client-bezogenen Attribute (Properties) für Queues und Kanäle entsprechend einrichten - eine neue Client-Verbindung zu Ihrem Host Queue Manager einrichten - sehen, wie die asynchrone PUT Option unter bestimmten Umständen den Message-Durchsatz erheblich steigern kann - sehen, wie dies auch durch die Read-ahead Funktion möglich ist - sehen, wie die neuen Attribute zur Begrenzung der Anzahl der zulässigen Kanalverbindungen pro Client greifen und sich auswirken Auf dem Windows-System werden Sie das Programm q.exe als Test-Anwendung verwenden. Dies ist ein sehr vielseitiges Utility-Programm, welches über als SupportPac MA01 schon seit langer Zeit allgemein verfügbar ist. http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24000647&loc=en_us&cs=utf-8&lang=en Die WMQ Client Funktion ist auf Ihrer Windows Workstation (bzw. VMWare Image) als Bestandteil der MWQ V7 Installation vorinstalliert und benötigt keine weitere Konfiguration. 1. Vorbereitende Maßnahmen Sie legen in für Ihren Host-QMgr ein paar neue Queues an, gegen welche die anschließenden Client-Funktionen laufen werden, und richten die ClientVerbindung anschließend ein. 1.1. Öffnen Sie in Ihrer TSO CNTL-Session ( swap 1 ) das Member WBI#$%.WMQV7.CNTL(DEFCLI) im Edit-Modus. Dieses Member enthält DEFINE QLOCAL Commands für zwei Queues und eine DEFINE CHANNEL Command zum Anlegen eines neuen ServerConnection Channels für Ihre Client-Anbindung. 1.2. Ändern Sie- wie gehabt - zunächst mittels change all Funktion alle Instanzen des Platzhalters ++TEAM++ in den variablen Teil Ihrer TSO ID, also z:. für WBI24A: Command ===> c ++TEAM++ 24A all Seite 29 von 47
1.3. Fügen Sie die folgenden Attribute bzw. Werte in den Definitionen ein, welche sich auf die neuen V7 Funktionen beziehen: 1.3.1. Für die Queue WBI+++.QUEUE.STANDARD: setzen Sie MAXDEPTH (die Max queue depth ) auf 1500 and stellen Sie sicher, dass DEFREADA ( Default read ahead ) auf NO... und DEFPRESP ( Default put response type ) auf Synchronous steht die letzten beiden Attribute entsprechen dem V6 Verhalten und sind in V7 Default. 1.3.2. Für die Queue WBI+++.QUEUE.NEW: setzen Sie die Max queue depth ebenfalls auf 1500 setzen Sie das Default read ahead Attrbiut auf YES... und Default put response type auf Asynchronous dies sind nun neue -V7- Settings 1.3.3. Für den Kanal WBI+++.SVRCONN: setzen Sie den Wert für MAXINST (maximale Anzahl der Instanzen dieses Kanals) auf 10, und den Wert für MAXINSTC (maximale Anzahl der Kanalinstanzen für einen einzelnen Client-Prozess) auf 2 1.4. Sichern Sie das Member. 1.5. Aktivieren dieser Objektdefinitionen 1.5.1. Öffnen Sie Öffnen Sie das Member UTLCMD in derselben Library im Edit- Modus, und ändern Sie in der letzten Zeile den Input Member Namen nach DEFCLIentsprechend dem eben gerade aufbereiteten Member. 1.5.2. Submitten Sie den Job in UTLCMD Er sollte schnell durchlaufen und mit CC=0 enden. 1.5.3. Kontrollieren Sie den Job Output im SDSF ( swap 2 ) Die Message, die wir am Ende des Outputs sehen möchten, ist diese: CSQU058I 3 commands issued and responses received, 0 failed Seite 30 von 47
2. Verbinden des Clients mit dem WMQ Host Queue Manager (Server) Dieser kurze Vorbereitungsschritt startet eine Windows Command Session mit den Einstellungen, die eine Client-Anwendung für die Verbindung zum Host Queue Manager benötigt und verifiziert die Erreichbarkeit des Server QMs für Client Programme. 2.1. Öffnen Sie auf Ihrem Windows Desktop den Ordner labfiles, und dort den Unterordner MQv7 2.2. Öffnen Sie in...\labfiles\mqv7 die Script-Datei WinCmd.cmd durch Rechts-Klick und Auswahl der Edit Funktion. 2.3. Ändern Sie die Platzhalterzeichen #,$,? wie folgt (manuell oder mit ReplaceFunktion)- auf jeden Fall sorgfältig : #$ numerischer Teil Ihrer Team-Kennung (also 24 für WBI24A) # die Zehner-Kennung der Team-ID = Host System Nummer? A oder B, gemäß der letzten Stelle Ihrer User-Kennung Sichern Sie die Datei. 2.4. Führen Sie das WinCmd.cmd Script aus (Doppelklick auf das File Icon)- es wird sich ein Windows Befehlsfenster öffnen. 2.5. In diesem Windows-Fenster tippen Sie als Befehlseingabe test ein (ohne Anführungszeichen- dadurch wird das WMQ Beispiel-Programm amqsputc gestartet und macht OPEN auf eine Queue. 2.6. Wenn Sie die folgende Anzeige sehen, hat die Anwendung den Queue Manager (und auch die Queue) erreicht und die Verbindung ist somit erfolgreich getestet: Seite 31 von 47
Andernfalls schließen Sie das Windows Fenster und gehen zurück nach 2.2.offensichtlich ist bei der Änderung der Variablen Werte etwas schief gelaufen zögern Sie nicht lange, nach Hilfe zu fragen... 2.7. Betätigen Sie einfach noch einmal die Enter-Taste (ohne Texteingabe)- dadurch wird das amqsputc Programm beendet (und signalisiert dies auch). 2.8. Das Windows Fenster offen lassen - nicht schließen! 3. Asynchronous PUT In diesem Übungsschritt werden Sie die Auswirkung der MQ V7 Funktion asynchronous PUT kennen lernen. Wie erwähnt, verwenden wir das q.exe Programm aus dem SupportPac MA01 für diese Übungen- damit Sie nicht soviel tippen müssen, haben wir die (recht kryptischen) Programmaufrufe in Scripte verpackt, die im Verzeichnis C:\Documents and Settings\Administrator\Desktop\labfiles\ MQv7\cmds hinterlegt sind- Sie dürfen die Scripte natürlich ansehen- deren Gestaltung hat allerdings nichts mit MQ V7 zu tun... 3.1. Schreiben von 1.000 Messages im Normal-Modus 3.1.1. Das put-std.bat Script schreibt mittels des q.exe Programms 1.000 Messages mit jeweils 100 Bytes Größe auf die zuvor angelegte Queue <uid>.queue.standard wobei der Top Level Qualifier (Ihre TSO ID) als Variable gestaltet ist. Starten Sie also das Script durch Eingabe von put-std <uid> im noch offenen Windows-Cmd-Fenster von zuvor, wobei Sie <uid> mit Ihrer vollen TSO User ID ersetzen, also zb. (für User WBI24): put-std WBI24A 3.1.2. Seien Sie etwas geduldig, wenn die Connecting connected to <QMgr> Angabe erscheint. Die nächste Nachricht, welches die Abschluss-Meldung mit ZeitAngabe ist, kommt erst, nachdem die 1.000 Messages geschrieben worden sind- in unserm Test-Fall war das nach gut 30 Sekunden: 3.2. Schreiben von 1.000 Messages mit der asynchronous PUT Option 3.2.1. Drücken Sie irgendeine Taste, wie angeraten, und geben Sie als nächstes, zum nochmaligen Schreiben von 1.000 Messages, aber diesmal auf die <uid>.queue.new, unter Verwendung der asynchronen PUT Option, ein: put-async <uid> - mit Ihrer vollen TSO User-Kennung, wie zuvor Seite 32 von 47
3.2.2. Wie unterscheidet sich die Reaktion (Anzeige) zu der von vorhin? Wir erwarten, dass die Wartezeit bis zur Abschluss-Nachricht des q-programms diesmal erheblich kürzer ist, z.b. wie hier unserem Test: 3.2.3. Wie ist dieser Unterschied des Message-Durchsatzes zu erklären? Durch die Verwendung der asynchronen PUT-Option erhöhte sich der Durchsatz bzw. verringerte sich die benötigte Zeit in unserem Test-Fall um mehr als den Faktor 15 wir erwarten bei Ihnen ein ähnliches Ergebnis. 3.2.4. Beenden Sie das Programm durch Drücken irgendeiner Taste. Wenn Sie möchten, überprüfen Sie, ob auf den beiden Queues tatsächlich jeweils 1000 Messages drauf stehen! Seite 33 von 47
4. Read-Ahead ( streamed MQGET ) Natürlich bietet es sich an, in dieser Lese(MQGET)-Übung die eben geschriebenen Messages wieder von den Queues abzuholen. Somit spielt sich diese Übung, völlig analog zur vorhergehenden, auch wieder im noch offenen Windows-Cmd-Fenster ab. 4.1. Standardmäßiges Lesen von Messages 4.2. Das Script zum Lesen der <uid>.queue.standard, in herkömmlicher Weise, heißt get-std. Geben Sie somit als Windows Command ein: get-std <uid> - mit Ihrer vollen TSO User-Kennung, wie zuvor 4.2.1. Wiederum ist nach Auslösen des Commands etwas Geduld gefragt- nach einiger Zeit wird sich das Ergebnis etwa wie folgt darstellen: 4.3. Lesen mit der Read-Ahead Option 4.3.1. Nehmen Sie die angezeigte Zeit zur Kenntnis, drücken Sie eine Taste und stoßen Sie mit folgender Eingabe das Lesen der (1.000) Messages auf der <uid>.queue.new an, die zur Verwendung der Read-Ahead Option konfiguriert ist: get-rh <uid> - mit Ihrer vollen TSO User-Kennung, wie zuvor 4.3.2. Wie groß ist der Performance/Durchsatz-Gewinn bei Ihnen? In unserem Test-Fall zeigt war das Ergebnis: ==> Faktor 16,6 (508 zu 30,6 msgs/sec)! 4.3.3. Beenden Sie das Programm aber lassen Sie das Windows-Cmd-Fenster offen! 4.3.4. Überprüfen Sie, ob die beidem Queues (<uid>.queue.standard und <uid>.queue.new) nun tatsächlich leer sind. Seite 34 von 47
5. Besonderheiten bei Async PUT und Read-Ahead Das war die eine Seite dieser Funktionen- ggf. dramatische Performance-Gewinne! Es gibt aber eine Kehrseite - und die kann man ebensogut in einer kleinen Übung sichtbar machen. 5.1. Standard-PUT mit Erreichen des MAXDEPTH Limits Wir versuchen nun, mit leicht abgewandelten Scripten, jeweils 2.000 Messages auf unsere beiden Test-Queues zu schreiben 5.1.1. Command-Eingabe zum herkömmlichen Schreiben von 2.000 Messages nach <uid.queue.standard> ist : put2-std <uid> 5.1.2. Das dauert jetzt natürlich noch etwas länger... Nach einiger Zeit erwarten wir eine Anzeige wie folgt: Wir erhalten diesmal keine Zeit-Angabe, sondern die Information, dass das Programm nach Auftreten des RC=2053 ( Queue full ) aufgehört hat zu schreiben. 5.1.3. Überprüfen Sie die Anzahl Messages auf der <uid>.queue.standard queue- wir erwarten, dass 1.500 Messages auf der Queue stehen. 5.2. Async PUT mit Erreichen des MAXDEPTH Limits 5.2.1. Command-Eingabe zum Schreiben von 2.000 Messages nach <uid.queue.new>, unter Verwendung von der Async PUT Option, wie in der Queue Definition hinterlegt : put2-async <uid> 5.2.2. Wie unterscheidet sich das Ergebnis auf der Ebene der q.exe AnwendungsNachrichten von vorhin? Wir erwarten, dass dies wie folgt aussieht: D.h. das q Programm behauptet, es habe 2.000 Messages geschrieben... 5.2.3. Wieviele Messages stehen tatsächlich auf der <uid>.queue.new queue?was halten Sie davon?? Seite 35 von 47
5.3. Lesen (MQGET) einzelner Messages bei aktiviertem Read-ahead Für diese Übung benutzen wir ein anderes Tool, das GUI Utility RFHUTIL, welches ebenfalls als SupportPac (IH02) öffentlich verfügbar ist. Es war ursprünglich und primär zur Verwendung mit WebSphere Message Broker gedacht, erweist sich aber aufgrund seiner Funktionsvielfalt als sehr vielseitig einsetzbar. 5.3.1. Geben Sie als Zeilen-Kommando im Windows-Cmd-Fenster ein: rfhutilc Das RFHUTIL(c) GUI wird sich öffnen: 5.3.2. Geben Sie im Queue Manager Name Feld den Namen Ihres Host Queue Managers ein, und im Queue Name Feld den Namen den vollen Namen der Standard Queuewie im obigen Screenshot für den WBI24A User dargestellt. 5.3.3. Klicken Sie auf den Read Q Button; dies löst einen MQGET Call aus, und 1 Message wird von der Queue gelesen. Wir erwarten, dass der erfolgreiche Lesezugriff im unteren Feld des RFHUTIL GUI wie folgt bestätigt wird: 5.3.4. Prüfen Sie nach, wieviele Messages sich nun noch auf der Queue <uid>.queue.standard befinden. Wir erwarten, dass es 1.499 sind 1.500 minus 1. 5.3.5. Ändern Sie nun den Q Namen im RFHUTIL Queue Name Feld nach <uid>.queue.new und klicken Sie abermals den Read Q Button, um auch einen MQGET Call gegen diese Queue auszulösen. Seite 36 von 47
5.3.6. Wenn RFHUTIL auch hier das Lesen einer Message bestätigt hat Prüfen Sie nun auch für <uid>.queue.new die aktuelle Anzahl von Messages auf der Queue. Sieht das bei Ihnen auch so -oder ähnlich- aus: 5.3.7. Und wieder fragen wir- zur anschließenden Diskussion: Was halten Sie davon? 5.3.8. Beenden Sie (Exit) RFHUTIL, aber lassen Sie das Windows Cmd Fenster weiterhin geöffnet! Hinweis: der folgende Absatz 6. -Die neue MQ Client ini File ist eine Info-only Übung, in der zusätzliche Hinweise zur Konfiguration der Read-Ahead Funktion gegeben werden. Seite 37 von 47
6. Die neue MQ Client ini File Die neue WMQ Cient Konfigurationsdatei mqclient.ini im Hauptverzeichnis der WMQ Installation auf Windows (und anderen verteilten Plattformen) kann verwendet werden, um spezielle Optionen die neuen ClientFunktionen betreffend zu konfigurieren. Wir schauen in diesem Abschnitt nur in die Datei hinein und vermitteln ein paar Hinweise; es werden keine Änderungen durchgeführt. 6.1. Öffnen der client.ini Datei Ihrer WMQ Installation auf Windows 6.1.1. Klicken Sie auf das folgende Icon in Ihrem Windows Desktop: Dadurch öffnet das Verzeichnis c:\program Files\IBM\WebSphere MQ in einem neuen Windows Explorer Fenster 6.1.2. Lokalisieren und doppel-klicken Sie die Datei mqclient. Dadurch startet das Notepad Programm und öffnet die Datei. 6.1.3. Was Sie sehen, sind die Default-Einträge, die bei der Installation erstellt werden: TCP: Sektion ( Stanza ) mit einem auskommentierten Eintrag die Pfad-Angaben für (eventuelle) User Exits 6.1.4. Gemäß der folgenden Tabelle kann das Verhalten der in der folgenden Übung genutzten Read-ahead Funktion in einer Stanza messagebuffer konfiguriert werden: MaximumSize - Maximale Größe des READ AHEAD Message Puffers ATTRIBUTE DATATYPE MINIMUM MAXIMUM SPECIAL VALUES MaximumSize Integer (KB 1024 bytes) 1 999999-1 Client bestimmt den Wert - Default! 0 Read ahead disabled UpdatePercentage - Puffer Füllstand in Prozent des Größe, bei welcher der Client dem Queue Manager signalisiert, dass weitere Messages ( Nachschub ) ausgeliefert werden sollen ATTRIBUTE UpdatePercentage DATATYPE Integer (%) MINIMUM 1 MAXIMUM 100 SPECIAL VALUES 1Client bestimmt den Wert - Default! PurgeTime Zeitintervall, nach welchem nicht gelesene Messages gelöscht (purged) werden. Seite 38 von 47
STANZA ATTRIBUTE DATATYPE MINIMUM MAXIMUM DEFAULT SPECIAL VALUES MessageBuffer PurgeTime Integer (seconds) 0 999999 0 0NO message purge (default) 6.1.5. Das folgende wäre ein Beispiel für eine gültige mqclient.ini Datei mit spezieller Konfiguration für die Read-Ahead Funktion: Diese Konfiguration würde in Bezug auf READ AHEAD (RA) bedeuten: Es wird ein RA Puffer von 200 kb verwendet wenn durch MQGETs von der Client Anwendung aus auf unter 50% Füllstand fällt, setzt der Client Code eine neue Lese-Anforderung an den MQ Server ab Messages im Puffer, die älter als 10 Minuten (600 Sek.) sind, werden gelöscht Seite 39 von 47
7. Verifizieren der MAXINST* Client Kanal Attribute 7.1. Öffenen Sie durch Doppelklick auf das (modifizierte) WinCmd Icon in Ihrem (Desktop)\labfiles\MQv7 Ordner entsprechende Icon zwei weitere Windows Command Fenster (wie in Schritt 2.4.) 7.2. Starten Sie in den Fenstern das test Script aus 2.5. aus: Eingabe test, dann enter. Wir erwarten, dass zwei Starts funktionieren, der dritte jedoch nicht, und der MQCONN des dritten Client Prozesses mit RC=2537 abgewiesen wird, gemäß dem folgenden Screenshot: 7.3. Sie können die Dokumentation für den MQRC=2537 im WMQ Online Infocenter nachschlagen Link zum Infocenter befindet sich auf Ihrem Windows Desktop. 7.4. Besonders aussagekräftig ist jedoch die Joblog Message der Host-Komponente. Schauen Sie im SDSF Screen Ihrer TSO Session ( swap 2 ) ins System Log (Eingabe log in der SDSF Command Zeile) und suchen Sie- am besten von hintennach der Message ID CSQX490E. Es sollte sich eine Message dieser Art finden: +CSQX490E +MQ24 CSQXRESP Maximum client instance limit 2, exceeded,channel WBI24A.SVRCONN, connection 192.168.17.30 Seite 40 von 47
- Übung 3: Asynchronous Consume Funktion Worum es in diesem Übungsteil geht In dieser Übung erhalten Sie Gelegenheit, erste praktsiche Erfahrungen mit den neue APIs MQCB und MQCTL zu machen, mit denen die mit WMQ V7 neu eingeführte Asynchronous Consume Funktion angesprochen wird. Sie werden: - ein in C geschriebenes Anwendungsprogramm analysieren, und dabei lernen, wir die MQCB und MQCTL Calls eingesetzt werden - dieses C-Programm ausführen und dabei sehen, wie ein Programm einen Listener gegen eine Queue aktiviert - dieses C-Programm ausführen und dabei mehrer Listener gegen verschiedene Queues aktivieren. Auch in dieser Übung wird als Anwendung ein MQ Client Programm verwendet, welches auf Windows läuft. 1. Analyse des Programms mqcb.c 1.1. Öffnen Sie das Beispiel Programm mqcb.c (wird mit WMQ V7 mitgeliefert) im Desktop-Ordner labfiles\mqv7\callbacklab durch Doppelklick auf das entsprechende File-Icon. 1.2. Schauen Sie sich den Source Code sorgfältig an. Das Programm hat zwei Haupt-Bestandteile: die Message Consumer Routine, welche die Messages verarbeitet das Hauptprogramm, welches: die Parameter einliest zum Queue Manager connectet die Queues öffnet die Message Consumer Routine(n) registriert Kontrolle an den Queue Manager übergibt, damit dieser Messages an die Consumer Komponente(n) ausliefern kann 1.3. Details zum Message Consumer Teil 1.3.1. Lokalisieren Sie die Message Consumer Prozedur. Seite 41 von 47
1.3.2. Beachten Sie die Parameter, die beim Prozeduraufruf übergeben werden. Diese schließen die zu verarbeitende Message ein, sowie den Message Descriptor und den MQBCB Control Block mit dem Call Back Kontext. Der Message Consumer Code beginnt mit einem Switch Statement, in welchem nach dem Call Typ gefragt wird (CallType in der Callback Kontext Struktur). Die Callback Routine kann auch aus anderen Gründen außer der Ankunft einer Message auf der Queue aufgerufen werden. 1.3.3. Beachten Sie die Bedingungen (cases), welche im switch Befehl unterschieden werden: Seite 42 von 47
der erste case-pfad behandelt die Verarbeitung einer breitst gestellten Message der zweite case-pfad bezieht sich auf einen Event - am ehesten wäre dies die Mitteilung, dass der Queue Manager heruntergefahren wird. 1.4. Details zum Hauptprogramm Das Programm liest die übergebenen Parameter und verbindet sich zum Queue Manager Jede der spezifizierten Input Queues wird geöffnet 1.4.1. Lokalisieren Sie die im Programmcode die Register a consumer Sektion. 1.4.2. Hier wird eine/die Message Consumer Routine bezeichnet, welche zur Verarbeitung ( consume ) ausgewählter Messages benutzt wird. Die Messages, welche dieser Routine übergeben werden, können aufgrund irgendwelcher Auswahlkriterien (MQMD Felder, Properties) bestimmt werden. Das bedeutet, dass Messages gezielt unterschiedlichen Consumer Routinen zugeordnet werden können. Der Name der (in diesem Fall nur einen) Message Consumer Routine ist MessageConsumer, und die erste MQCB Operation ist MQOP_Register. Nachdem die Callback Routine(n) registriert ist/sind, wird der MQCTL Command ausgeführt, mit welchem die registrierten Routinen aktiviert werden. 1.4.3. Lokalisieren Sie im Programmcode die Start the consumption of messages Sektion. 1.4.4. Die MQCTL Operation ist MQOP_START Seite 43 von 47
Hinweis: nach diesem Call bleibt der Mainline Thread aktiv (im Falle des MQCB.C Beispiel-Programms wartet das Programm auf das Drücken der Enter-Taste), ABER der ConnectionHandle (HConn) wird nun vom Queue Manager selbst verwaltet und wird zum Anstoßen (Dispatch) der Consumer Routinen verwendet. 1.4.5. Lokalisieren Sie im Programmcode die Stop consumption of messages Sektion. 1.4.6. Die MQCTL Operation ist MQOP_STOP Damit beendet das Programm die Callback-Funktion und kann regulär terminieren. 2. Ausführen des Callback Beispiel Programms MQCB 2.1. Definieren von drei neuen Queues für diese Übung 2.1.1. Öffnen Sie in Ihrer TSO CNTL-Session ( swap 1 ) das Member WBI#$%.WMQV7.CNTL(DEFCB) im Edit-Modus. Dieses Member enthält DEFINE QLOCAL Commands für drei Queues <uid>.ql01,-ql02 und -QL03. 2.1.2. Ändern Sie- wie gehabt - mittels change all Funktion alle Instanzen des Platzhalters ++TEAM++ in den variablen Teil Ihrer TSO ID, also z:. für WBI24A: Command ===> c ++TEAM++ 24A all 2.1.3. Öffnen Sie das Member UTLCMD in derselben Library im Edit-Modus, und ändern Sie in der letzten Zeile den Input Member Namen nach DEFCBentsprechend dem eben gerade aufbereiteten Member. 2.1.4. Submitten Sie den Job in UTLCMD Er sollte schnell durchlaufen und mit CC=0 enden. 2.1.5. Kontrollieren Sie den Job Output im SDSF ( swap 2 ) Die Message, die wir am Ende des Outputs sehen möchten, ist diese: CSQU058I 3 commands issued and responses received, 0 failed Seite 44 von 47
2.2. Ausführen des MQCB Programms gegen eine einzelne Queue 2.2.1. Falls Sie das Windows Command Fenster aus der vorherigen Übung noch offen haben, können Sie dieses verwenden; sonst öffnen Sie eines durch Doppelklick auf das Objekt WinCmd.cmd im Desktop-Ordner labfiles\mqv7 wie im Schritt 2.4. der Übung 2 (Seite 31). 2.2.2. Starten Sie das MQCB Programm durch Eingabe von mqcb <uid>.ql01 (wobei Sie <uid> durch Ihre volle TSO ID ersetzen) Die Ausgabe im Command Fenster wird so aussehen (für WBI24A): 2.2.3. Öffnen Sie über das (\labfiles\mqv7\)wincmd Script ein weiteres Command Fenster und ordnen Sie dies am besten neben dem ersten Fenster mit dem laufenden MQCB Programm an, so dass Sie beide Fenster gemeinsam sehen können. 2.2.4. Starten Sie hier das PUT-Sample Programm amqsputc durch Eingabe von amqsputc <uid>.ql01 Das Programm wird starten und auf die Eingabe von Message Texten warten: 2.2.5. Geben Sie nun zwei oder drei einfache Text-Nachrichten ein, wobei Sie jedes Enter den Abschluss einer Nachricht kennzeichnet; Sie beenden das Beispiel Programm durch zweimaliges Enter 2.2.6. Beachten Sie, was sich im mqcbfenster getan hat- das Programm hat die Nachrichten erhalten und entsprechend der Consumer Routine unter Hinzufügen einer Längenangabe ausgegeben. Seite 45 von 47
2.3. Ausführen des MQCB Programms gegen mehrere Queues Wir verwenden die Windows Command Fenster aus dem vorherigen Schritt weiter mit dem Hinweis, dass zuvor eingegebene Commands mit der Pfeilnach-oben Taste zur neuerlichen Ausführung (mit oder ohne Modifikation) wieder dargestellt ( retrieved ) werden können. 2.3.1. Starten Sie das MQCB Programm nun gegen alle drei zuvor angelete Queues, wobei Sie die QL03 doppelt benennen. mqcb <uid>.ql01 <uid>.ql02 <uid>.ql03 <uid.ql03> Für User WBI24A sieht dies so aus: 2.3.2. Sehen Sie sich im MQ Explorer die *QL0x Queues an- die Open Input Counts sollten belegen, dass die Queues geöffnet sind, die *QL03 sogar doppelt. 2.3.3. Schreiben Sie im zweiten Fenster mit dem amqsputc Beispiel-Programm nun jeweils eine Message auf jede der drei Queues, indem Sie amqsputc nacheinander für jede Queue aufrufen und eine kurze Text Nachricht als Message eingeben (Abschluss jeweils durch <Enter> ohne Eingabe):n Seite 46 von 47
2.3.1. Geben Sie nun zwei oder drei einfache Text-Nachrichten ein, wobei Sie jedes Enter den Abschluss einer Nachricht kennzeichnet; Sie beenden das Beispiel Programm durch zweimaliges Enter Eingabe-Beispiel für User WBI24A siehe Screenshot nächste Seite 2.3.2. Wiederum interessiert, was sich im mqcb-fenster getan hat- es sollte ähnlich aussehen, wie hier dargestellt: Beachten Sie: eine und nur eine Message wurde für QL03 ausgeliefert, obwohl Sie zwei Listener für diese Queue registriert hatten. Dies bedeutet: das MQ-Paradigma der once and only once delivery greift auch in diesem Fall End of WMQ V7 Update Exercises Seite 47 von 47