Transaction & Messaging Congress 96

MQSeries - How & Where Do I Start

Måndag 4/11 14.00
Harry Halliwell, IBM Hursley

MQSeries Platforms
Harry Halliwell beskrev de olika plattformar som MQSeries kör på idag. Det är de mest förekommande med ett par undantag (SGI och Apple). De olika implementationer som finns idag är av två grundvarianter; Level1 och Level2. Level1 är en första version av MQSeries som inte stöder alla funktioner som Level2 gör. Det tråkiga i den här typen av differentiering är att det är svårt att veta vilka OS-versioner av MQSeries som stöder vilken nivå. Det syns tyvärr inte på versionsnumret. Den aktuella MQSeries-versionen för MVS är 1.1.1.4 och för OS/400 något på 3. Det är dock enligt Halliwell inget problem, för IBM satsar nu på att få alla Level1-versioner uppgraderade till Level2.
Level1-plattformar idag är IBM VSE/ESA, Digital VMS VAX, Tandem Guardian (finns i Level2-betatest som genuin Tandemapplikation), SCO Unix och UnixWare.
Några plattformar har inga serverversioner, så som DOS, och en del har inga klientversioner.

MQSeries Basics
Halliwell var ganska snabb i sitt framförande och mycket teknisk. Han hade inte alltid tråden klar framför sig under presentationen utan kunde ta delarna i lite olika ordning.
Han beskrev dock lite grundkonventioner i MQSeries. Han berättade att MQ är byggd på en gemensam grund för alla plattformar. Det gör att namnregler mm är gemensamt i MQ för olika plattformar och för MQI-APIt för olika programmeringsspråk. Det innebär också att något kan skilja sig jämfört med praxis på någon plattform eller något programspråk.
Det absolut viktigaste som Halliwell ansåg att man skulle tänka på inför en MQ-installation var att komma överens om alla namn, och då även tänka på om det ska vara små eller stora bokstäver. Det är av största vikt för att systemet skall fungera. Om olika grupper installerar och konfigurerar systemen utan att ha kommit överens om generella regler och konfiguration, kommer det att bli stora problem! MQSeries har i sig ingen egentlig namnstruktur (förutom transaktionsköernas defaultnamn) utan det är viktigt att hitta en egen struktur som sedan hålls gemensam inom företaget/installationerna.

Queue Manager
Oftast installerar man endast en queue manager per server, men det kan av olika anledningar vara så att man installerar flera, tex för test. Namnet bör vara ganska kort, och om det är möjligt, ansåg Halliwell, så skulle queue managern döpas med samma namn som den server den körs på (men egentligen borde det inte vara så, då queue managern blir 'låst' vid en definierad plats i nätet och med allt dynamiskt tänkande i bakhuvudet borde det vara lite mer dynamiskt än så).

Queues
När man skapat sin queue manager ska man skapa sina köer som behöver finnas på queue managern. Köerna delas upp i

• Lokala köer som är grunden i MQSeries. Det är de lokala köerna man använder som bas för meddelandeöverföring. Den lokala kön är som man hör på namnet lokal på den aktuella queue managern.
• Remoteköer är köer som definierats på en queue manager för vidare distribution till en lokal kö på en annan queue manager. En applikation skriver på remotekön (applikationen ser ingen skillnad på en remotekö och en lokal kö) på samma sätt som den skriver på en lokal kö. Queue managern skickar meddelandet till den queue manager som ska ha meddelandet. Den queue managern ser sedan till att lägga meddelandet på den lokala kö som specats.
• Aliasköer är till för att ge köer ett alias. För att slippa ändra i en applikation eller i en ini-fil kan man ändra i ett alias. I och med att applikationerna använder sig av aliaskön för att komma åt den egentliga kön, så kan man konfigurera om aliaskön under drift och skicka meddelanden till en annan kö istället. Kan användas för test.
• Modell- och dynamiska köer används för att skapa dynamiska köer. Dessa används tex när man vill ha reply från en mottagare utan att ha definierat en särskild kö att skicka och ta emot svaret på.

Ett viktigt tips när det gäller att döpa köer är att de inte skall beskriva kötypen i namnet, och heller inte en exakt beskrivning av köns placering i nätstrukturen. Om man följer dessa tips blir systemet mer flexibelt. Det som egentligen är viktigt i det hela är att programmet som sänder data inte ska behöva bry sig om hur kön ser ut, vart den tar vägen, och sist men inte minst, vilket/vilka program som läser och behandlar meddelandet!
Det finns en del speciella lokala köer som Halliwell beskrev.

• Dead Letter Queue är en kö som används för att lägga meddelanden som av nån anledning inte kunde bli hanterade av MQSeries, tex för att den kö som angetts som remotekö i meddelandet inte finns upplagd på queue managern som meddelandet skickats till. Meddelanden som hamnar här kan komma från olika köer och ha olika format, så det gäller att vara medveten om vad det är man kollar om man går in och läser en DLQ.
  OBS! Det skall alltid finnas en DLQ för en queue manager! Om det inte existerar en DLQ och det kommer ett meddelande som inte kan hanteras av en kanalprocess (MCA) kommer kanalen att stängas tills felet med meddelandet fixats, och det är inte en situation att rekommendera. Alla andra meddelanden som ska förbi den kanalen stoppas!
• Administrations- och eventkö är systemnära köer. Administrationskön kan användas för att administrera en annan queue manager på distans. Det är inte det mest kraftfulla sättet att lösa distribuerad administration på, men det kan ge en enkel möjlighet att se hur en queue manager är konfigurerad. För mer avancerade möjligheter för SM fanns ett helt seminarium om detta (Vendor session - MQView).
• Initieringskö används för triggning och automatisk start av processer.
• System default queues är köer som är upplagda för att hjälpa till vid skapandet av köer. I dessa defaultköer ligger defaultvärden som utnyttjas om ett attribut vid skapandet av en kö är tomt.

Message channels
En kanal är den låga nivån i MQSeries och genom sin Message Channel Agent, som är en process som hanterar kommunikationen på kanalen, sänder eller mottager kanalen data mellan den lokala queue managern och en annan remote queue manager.
På samma sätt som i övriga MQSeries gäller det att enas om en namnstandard och ett bra tips här är att ha queue manager-namnen inlagda i kanalnamnet. Den är ju till skillnad från köer fast kopplad till de två queue managers som kanalen definierats för. Ex QMCSU.QMCBO för kommunikation mellan Sundsvall och Borlänge och QMCBO.QMCSU för kanalen som skickar meddelanden från Borlänge till Sundsvall.
En kanals MCA hanterar kommunikationen för en sk transmissionskö. Det är en särskild form av lokal kö som inte går att skriva på för normala applikationer utan är bara till för att samla upp meddelanden för sändning genom en kanal. Det här innebär att flera remoteköer kan ha samma transmissionskö definierad, och de meddelanden som då skickas i dessa köer läggs i den specificerade transmissionskön och skickas av MCAn via den gemensamma kanalen. Det är en mycket vanlig konfiguration att bara ha en kanal som servar all trafik mellan två queue managers.

När kanalerna är definierade gäller det att verifiera att de är konfigurerade rätt. Det kan man enkelt göra genom att först starta kanalen, och sen pinga tcp/ip för att se att nätet är uppe och sen göra en PING CHANNEL i MQSeries kommandointerface (runmqsc).
Start av en kanal sker oftast genom att man definierar en sk trigger monitor (Channel Initiator) som startar en MCA så fort det kommer in data i transmissionskön som skall servas av MCAn. I Level2 startas den mottagande kanalens MCA automatiskt när en sändande MCA startas, men i Level1 måste kanalerna startas på båda sidor innan trafik kan ske på kanalen.

Istället för att definiera ett kanalpar för varje kombination av queue managers som det finns i nätet finns det möjligheter att routa meddelanden i en queue manager. Hur det går till beskrivs närmre i Distributed Queuing - How to Set up an MQSeries network.

Halliwell berättade också om möjligheten att ha flera kanalpar mellan två queue managers. Det är också ett ämne som behandlades i Distributed Queuing, men han berättade lite om vad som kan vara anledningen till att man vill definiera flera kanalpar. Det kan tex vara att ett kanalpar är utrustat med krypteringsmöjligheter vilket skulle sänka kapaciteten på den ordinarie kanalen.En typ av meddelanden kanske inte kan ligga i en transmissionskö och vänta på att bli servad av den ordinarie MCAn utan måste gå så snabbt som möjligt till den mottagande queue managern, och då kan en separat VIP-kanal användas där transmissionskön inte är lika frekvent använd. Det meddelandet behandlas då snabbare än om det skulle ha sänts i den ordinarie kanalen, trots att det är samma nätverk som används.

Idle processing
En annan skillnad mellan de två level-versionerna är att Level1 låter ett anrop till MQGET ligga och polla den kö som skall läsas. Det kan ta en stor del av processorkraften (beroende på OS) och därför är Level2 omskriven så att den yildar systemet vid väntan på meddelanden.
I vissa OS finns det möjligheter till SIGNAL-hantering, men det gick Halliwell inte in på.

System administration
Alla plattformar har möjligheter till lokal administration. Det är en mycket modest form av SM där mycket handlar om operationer från kommandoprompten. I Level2 introducerades 'single point of control' där man har möjligheten att administrera queue managers via nätverket från en enda maskin. Genom en speciell kommandokö kan man skicka kommandon enligt MQSC-format (det finns ett annat format som kallas PCF som används av applikationer, men det beskrivs inte här) till en remote queue manager och få den att processa kommandot och skicka svaret tillbaka. Det är inget avancerat system och vissa saker går inte alls att genomföra, som tex att starta och stoppa en queue manager. För att kunna komma upp i den nivån av SM krävs en tredjepartsprodukt, så som MQView som visades i Vendor session - MQView. Det finns fler och jag fick med mig en del broschyrer från olika företag om detta.

Instrumentation
Det finns möjligheter i MQSeries att låta MQ rapportera om status i systemet. Det kan göras genom slå på rapportering av events vid olika händelser i system, tex en kö blir för full osv. Dessa meddelanden kan skickas till 'remote control points' för behandling.

Support pacs
IBM har något som kallas support pacs på webservern i Hursley. Här finns en hel del kod i olika format, för olika användningsområden, för olika plattformar och i olika supportnivåer. Tex alla klienter som finns för MQSeries ligger för DL här. Istället för att skicka ut alla klienter till alla MQ-installationer (vilket man försökte med förut) läggs nu klienterna upp centralt, och de man behöver tankar man hem och använder.
Bland support pacsen finns även exempelkod, utilities, olika gränssnitt som tex det för Lotus Notes. Dessa support pacs har olika nivåer i grad av support från IBM:

1. For IBM fee based services
2. Free, AS-IS
3. Free, supported

Adressen är http://www.hursley.ibm.com/mqseries/txppacs/txpsumm.html.

Where to Learn More
IBM håller en mängd kurser i ämnet och en del av dessa är:

Det finns beskrivet en del om kurser på http://www.training.ibm.com/usedu.