WebSphere optimerade lokala adaptrar

IBM WebSphere Optimized Local Adapters (OLA eller WOLA) är en funktionell komponent i IBM :s WebSphere Application Server för z/OS som tillhandahåller en effektiv korsminnesmekanism för samtal både inkommande till WAS z/OS och utgående från z/OS. Eftersom den undviker överbelastningen av andra kommunikationsmekanismer, kan den utbyta meddelanden i hög volym. WOLA är en förlängning av den befintliga mekanismen för utbyte av korsminnen i WAS z/OS, där WOLA tillhandahåller ett externt gränssnitt så att z/OS-adressutrymmen utanför WAS z/OS-servern kan delta i utbyten av korsminnen. WOLA stöder anslutning mellan en WAS z/OS-server och en eller flera av följande: CICS, IMS, Batch, UNIX Systems Services och ALCS. WOLA gjordes först tillgängligt i WAS z/OS version 7, Fixpack 4 (7.0.0.4). Funktionsförbättringar har dykt upp i efterföljande fixpack som dokumenterats i den här artikeln.

Historia

WebSphere Optimized Local Adapters for WAS z/OS (WOLA eller OLA för kort) har sitt ursprung i en önskan att tillhandahålla en effektiv inkommande anropsmekanism; det vill säga från utanför Java EE- miljön in i den för att utöva Java EE-tillgångar. Detta krav var särskilt uttalat på z/OS där traditionell batchbearbetning sökte användningen av en växande bas av programmeringstillgångar baserade på Java EE och EJB-teknologi.

Andra inkommande lösningar fanns, till exempel:

Medan var och en hade sina respektive styrkor; var och en hade också sina speciella brister: overhead och latens; svårighet att bygga; eller brister i säkerhets- eller transaktionsutbredningsmodellen.

Detta var den ursprungliga designpunkten för de optimerade lokala adaptrarna. Arkitekterna bakom lösningen utökade designen till att inkludera dubbelriktade anrop: inkommande till WAS z/OS från ett externt adressutrymme och utgående från WAS till ett externt adressutrymme.

Tekniska stiftelsen

Arkitekterna bakom denna lösning valde att utnyttja ett befintligt element i WAS z/OS-designen som kallas "lokal kommunikation", en korsminnesmekanism som används av WebSphere Application Server för z/OS sedan V4.x-dagarna som optimerade IIOP-trafik mellan applikationer servrar på samma LPAR. OLA är i huvudsak en externisering av den befintliga korsminnesmekanismen så att adressutrymmen utanför WAS z/OS kan ansluta och utbyta meddelanden över ett delat minnesutrymme.

Externa adressutrymmesprogram får åtkomst till OLA-gränssnittet med hjälp av en uppsättning medföljande API:er. Java-program som körs i WAS z/OS får åtkomst till OLA-gränssnittet genom en implementering paketerad som en standard JCA-resursadapter.

Aktuell support

De för närvarande stödda externa adressutrymmen som stöds för WAS z/OS OLA är:

Programmeringsspråken som stöds i de externa adressutrymmena är:

Java är programmeringsspråket som används för att komma åt WAS z/OS OLA inifrån Java EE-behållarna i WAS z/OS.

Funktion Uppdateringshistorik

Funktionsstödet för IBM WebSphere Optimized Adapters har uppdaterats när nya versioner eller fixpaket släpps. Funktionen gjordes först tillgänglig i WAS z/OS Version 7 Release 0 Fixpack 4 nivå (7.0.0.4).

Funktionella uppdateringar, del 1
Funktionella uppdateringar, del 3

7.0.0.4

WOLA introducerades med Fixpack 4 till WAS z/OS Version 7 Release 0-produkten. Tillämpning av underhåll resulterade i en ny katalog i produktfilsystemet som tillhandahåller WOLA-moduler, delade objekt, JCA-resursadapter och utvecklingsklassbibliotek. Ett skalskript (olaInstall.sh) skapade de nödvändiga UNIX-symboliska länkarna från runtime-miljön till produktinstallationsfilsystemet.

De funktioner som stöddes i versionen 7.0.0.4 var:

  • Stöd för CICS, Batch, USS och ALCS
  • Enfas commit för utgående WAS till CICS (2PC till CICS TS 4.1 tillhandahålls med 7.0.0.12)
  • Tvåfas commit för inkommande CICS till WAS
  • Inbyggda API:er
  • JCA resursadapter

7.0.0.12

Fixpack 12 till WAS z/OS Version 7 Release 0 gav två uppdateringar till WOLA-stödet:

  • Stöd för WOLA och IMS
  • Tvåfas commit-transaktionsbehandling från WAS utgående till CICS TS 4.1

8.0.0.0

WebSphere Application Server för z/OS Version 8 Release 0 fortsatt stöd för WebSphere Optimized Local Adapters. WOLA skickades inbyggt i produkten, vilket innebar att det inte längre krävdes att köra olaInstall.sh för att skapa UNIX symboliska länkar till produktfilerna. Dessutom tillhandahölls följande funktionsuppdateringar:

  • Stöd för stora meddelanden i flera segment (större än 32K i storlek) för arbete med IMS
  • Stöd för klassificering av inkommande transaktioner av WOLA-samtal separat från IIOP-samtal
  • Identifiering inom SMF 120.9-posten för WOLA-anrop som WOLA snarare än IIOP
  • Identifiering av resursfel och alternativ JNDI-failover

Resource Failover och Failback

Denna funktion tillhandahåller ett sätt att upptäcka förlust av en dataresurs kopplad till en JCA-anslutningsfabrik och automatiskt misslyckas med en definierad alternativ JNDI. Detektering av primär dataresursåterställning och failback är också en del av denna funktionella design. Resursfailover-designen finns i WebSphere Application Server version 8 på alla plattformar för JDBC och JCA. WAS z/OS version 8 ger stöd för WOLA-resursfailover som en del av det allmänna stödet för JCA-resursfailover. Anrop av failover inträffar när ett konfigurerbart tröskelvärde för getConnection()-fel inträffar. Efter att failover har anropats, dirigeras alla nya getConnection()-förfrågningar till den alternativa anslutningsfabrikens anslutningspool. Failback inträffar när WAS z/OS fastställer att den felaktiga primära dataresursen har returnerats. Nya getConnection()-förfrågningar behandlas mot den primära anslutningsfabriken.

Ett vanligt användningsmönster för denna funktion är utgående till CICS där mål-CICS-regionen är en routingregion. Denna failover-funktion ger möjligheten att utforma flera routningsregioner så att förlusten av en enskild routingregion inte påverkar den övergripande tillgängligheten av CICS totalt.

Flera anpassade egenskaper för anslutningspool lades till för att stödja denna resurs-failover- och failback-mekanism:

  • failureThreshold - antalet på varandra följande getConnection()-fel som måste inträffa innan automatisk failover anropas
  • alternateResourceJNDIName - JNDI-namnet för den alternativa anslutningsfabriken som ska användas om automatisk failover anropas
  • resourceAvailabilityTestRetryInterval - intervallet i sekunder som WAS använder för att testa för retur av primär resurs

Obs! Det finns andra anpassade egenskaper för anslutningspoolen för den här funktionen. Sök på strängen "cdat_dsfailover" i WAS z/OS InfoCenter för en komplett lista.

8.0.0.1 / 8.5.0.0

Obs: WAS z/OS 8.5.0.0 ger WOLA-stöd funktionellt identiskt med 8.0.0.1

Fixpack 1 till WebSphere Application Server för z/OS version 8 gav följande funktionsuppdateringar till WOLA:

  • 64-bitars anropbara inbyggda API:er för C/C++-program som arbetar i 64-bitarsläge
  • SMF 120 subtyp 10 poster för WOLA utgående samtal från WAS (SMF 120 subtyp 9 fångar inkommande samtalsinformation)
  • Arbetsfördelning - möjligheten att runda utgående samtal över flera externa registreringar med samma namn
  • Proxystöd för fjärråtkomst - detta tar två former: inkommande och utgående

64-bitars Callable Native API-moduler

Före 8.0.0.1 levererades de inbyggda API-modulerna endast i 31-bitars anropsbart format. Dessa moduler hade prefixet BBOA* med fyra tecken associerat med varje modulnamn.

Med 8.0.0.1 finns både 31-bitars och 64-bitars anropsbara API-moduler. 31-bitarsmodulerna behåller prefixet med fyra tecken BBOA* för varje modulnamn. 64-bitarsmodulerna bär prefixet BBGA* med fyra tecken för varje modulnamn.

Antalet API:er är detsamma som tidigare: 13 specifika API:er. Användningen är densamma som tidigare.

Infocentersökning: cdat_olaapis

SMF 120,10 för WOLA utgående samtal

I WAS z/OS V7 var WOLA-stödet för SMF begränsat till endast inkommande samtal. Inkommande WOLA-anrop till mål-EJB i WAS z/OS-behållaren identifierades som IIOP-anrop och fångades av SMF som IIOP-anrop, omöjliga att skilja från andra IIOP-anrop. Den normala WAS z/OS SMF 120 subtyp 9-posten (eller 120,9 i stenografi) användes för att fånga inkommande samtalsinformation.

Med WAS z/OS 8.0.0.0 modifierades SMF 120.9-inspelnings- och fångstfunktionen för att identifiera inkommande WOLA-samtal separat från inkommande IIOP-samtal.

Med WAS z/OS 8.0.0.1 skapades SMF 120.10-posten för att fånga information om utgående samtal från WAS z/OS. SMF 120.10-posten har åtta sektioner:

  • Platformneutral serverinformationssektion
  • z/OS-serverinformationsavsnittet
  • Avsnittet Information om utgående begäran
  • WOLA Outbound Request typspecifik sektion
  • Utgående begäran transaktion kontext avsnitt
  • Säkerhetskontextavsnittet för utgående begäran
  • Utgående begäran CICS kontextavsnitt
  • OTMA utgående begäran typspecifik sektion

En post skapas för varje utgående begäran.

Infocentersökning: rtrb_SMFsubtype10

Arbetsfördelning

Denna funktionsuppdatering ger möjlighet att distribuera utgående samtal över flera externa adressutrymmen som är registrerade på en given WAS z/OS-server med samma registreringsnamn. Ett gemensamt användningsmönster för detta skulle ha flera CICS-regioner med samma tillståndslösa målprogramtjänst utplacerad. En ny miljövariabel skapades för att indikera vilken typ av arbetsfördelning som önskas. Följande illustrerar användningen av denna funktion:

OLA Work Distribution.jpg

InfoCenter-sökning: cdat_olacustprop

Proxysupport: Inkommande och utgående

Korsminnesnaturen för WOLA-kommunikation innebär att WAS z/OS-servern och det externa adressutrymmet måste vara på samma logiska z/OS-partition (LPAR). WAS z/OS 8.0.0.1 tillhandahåller en proxyfunktion som gör att WOLA-anropare och WOLA-mål kan lokaliseras separat. Detta inkluderar plats på andra operativsysteminstanser än z/OS. Den här funktionen har två format: proxystöd för utgående samtal och proxystöd för inkommande samtal.

Proxysupport för utgående samtal

Detta tillhandahåller en mekanism genom vilken Java-applikationer kan använda den medföljande WOLA JCA-resursadaptern för att komma åt ett måladressutrymme på fjärrstyrd z/OS. Ett exempel på användningsmönster skulle vara utveckling eller test av en föreslagen applikation. Åtkomst till WOLA-anslutningen med korsminne på mål-z/OS-systemet tillhandahålls av en medföljande WOLA-proxyapplikation installerad i en WAS z/OS-server som är aktiverad för WOLA. Följande bild illustrerar topologin:

OLA Proxy Outbound Calls.jpg

Nätverksflödet från applikationen till WAS z/OS-systemet sker via IIOP. WOLA-anslutningsfabriken informeras om detta IIOP-flöde till proxyn genom flera nya anpassade egenskaper till anslutningspoolen. Proxyapplikationen på WAS z/OS tar emot samtalet och vidarebefordrar det via en faktisk korsminnes WOLA-anslutning till den namngivna måltjänsten.

Denna topologi har begränsningar jämfört med utgående WOLA-anrop på samma z/OS LPAR: globala transaktioner som kräver tvåfas commit kan inte spridas över IIOP-anslutningen till WOLA-proxyn, och användaridentiteten på WAS-tråden kan inte hävdas i måltjänsten på z/OS.

Proxysupport för inkommande samtal

Detta tillhandahåller en mekanism genom vilken icke-Java-applikationer i ett externt adressutrymme kan göra inkommande anrop till en mål-WOLA-aktiverad EJB i en fjärrstyrd WAS-instans, antingen på en annan z/OS LPAR eller en distribuerad WAS-plattform. Samma medföljande WOLA-proxyapplikation installerad i en lokal WAS z/OS-instans krävs för att hantera det initiala WOLA-anropet med korsminne och vidarebefordra det till den namngivna mål-EJB på fjärr-WAS-instansen. Följande bild illustrerar topologin:

OLA Proxy Inbound Calls.jpg

Mål-WOLA-aktiverade EJB är omedvetna om att proxyn används. Det inkommande flödet kommer som ett IIOP-anrop precis som det gör om WOLA med korsminne på samma LPAR användes. Det anropande programmet måste indikera att flödet kommer att använda proxytjänsten. Detta görs med en parameter på BBOA1INV (eller BBOA1SRQ) på 2 för parametern requesttype. Detta säger åt den lokala proxyapplikationen att behandla begärd tjänst, som anges som JNDI-namnet för mål-EJB, som en begäran att anropa EJB med IIOP. Detta kräver att de lokala och fjärranslutna WAS-instanserna har federerade namnutrymmen eller fungerar som en enda cell för att JNDI-uppslagningen ska lyckas.

8.0.0.3 och 8.0.0.4 / 8.5.0.1

I 8.0.0.3 (och 8.5.0.1) ingår WOLA-stöd i IBM Integration Designer för BPEL-processer.

I 8.0.0.4 (och 8.5.0.1) har stödet uppdaterats för att inkludera RRS-transaktionskontextbekräftelse från IMS-beroende regioner till WAS över WOLA:

  • Applikationer i IMS-användning ställer in flaggan "transaktionsstödd" på register-API
  • Mål-WAS-miljön har ola_rrs_context_propagate = 1 miljövariabel inställd och aktiverad
  • IMS Control Region måste köras med RRS=Y

8.0.0.5 (och 8.5.0.2)

Fixpack 8.0.0.5 / 8.5.0.2 gav två funktionella förbättringar: (1) RRS-transaktionskontextbekräftelse från WAS till IMS över WOLA / OTMA, och (2) förbättrat stöd för CICS-kanaler och behållare.

För IMS-transaktion:

  • IMS Control Region måste köras med RRS=Y
  • Mål-WAS-miljön har ola_rrs_context_propagate_otma = 1 miljövariabel inställd och aktiverad

För utökat stöd för CICS-kanaler och behållare var stödet för CICS-kanaler och behållare före 8.0.0.5 / 8.5.0.2 begränsat till en enda kanal med fast namn för både begäran och svar, och en enda behållare av typen BIT eller CHAR. Med 8.0.0.5 / 8.5.0.2:

  • Skicka och ta emot en eller flera behållare från målet CICS-programmet
  • Kanalnamnet ställs in av dig med metoden setLinkTaskChanID().
  • Kanaltyp ställs in av dig med metoden setLinkTaskChanType().
  • Namnen på de individuella begärandebehållarna ställs in genom att lägga till data till MappedRecord, med put()-metoden.
  • Nycklarna till MappedRecord motsvarar CICS-behållarens namn, och motsvarande värde kommer att användas för att fylla behållaren i CICS.
  • Svarsbehållarens namn kommer att extraheras från kanalen efter att CICS-begäran är klar, och fylls i ett nytt MappedRecord, som returneras till klienten.

Komponenter

De optimerade lokala adaptrarna kan kategoriseras i följande komponenter:

  • Gränssnittsmoduler -- ger programmatisk åtkomst till OLA-gränssnittet och OLA-API:erna
  • CICS Task Related User Exit, Link Task Server och kontrolltransaktion -- tillhandahåller en förenklad mekanism för att stödja utgående samtal för att programmera tillgångar i CICS.
  • JCA Resource Adapter -- tillhandahåller gränssnittet mellan Java-miljön och den externa miljön
  • Support för utvecklingsverktyg -- tillhandahåller de stödjande klasserna för att utveckla OLA-aktiverade applikationer
  • Samples -- en uppsättning C/C++, COBOL och Java-prover som illustrerar användningen av programmeringsmodellen

Översikt över CICS-stöd

De optimerade lokala adaptrarna implementeras i CICS som en Task Related User Exit (TRUE). Det är detta som ger den väsentliga anslutningen från CICS-korsminne till WAS z/OS-adressutrymmet.

Dessutom tillhandahålls en Link Server Task (BBO$) och en Link Invocation Task (BBO#) för samtal från WAS till CICS. BBO$/BBO# länkserveruppgiften skyddar programmeringsspecifikationer från CICS-program. OLA-anropet från WAS hanteras av dessa tillhandahållna uppgifter, och det namngivna CICS-programmet anropas med standardanropet EXEC CICS LINK. Det namngivna CICS-programmet förblir oförändrat och omedvetet om att samtalet kom från WAS som använder OLA. Målprogrammet i CICS måste kunna anropas med ett LINK-anrop. Både COMMAREA [ förtydligande behövs ] och kanaler/behållare stöds.

WOLA-Link-Server.jpg

En BBOC-transaktion tillhandahålls också för att tillhandahålla en uppsättning kontrollkommandon för att göra saker som att manuellt starta TRUE (om inte i PLTPI), stoppa TRUE, starta och stoppa länkservern, såväl som andra kontroll- och hanteringsfunktioner.

OLA-programmeringsgränssnittsmodulens biblioteksdatauppsättning måste kopplas till CICS-regionens DFHRPL DD-sats.

Följande bild sammanfattar WOLA CICS-stödet för transaktionsutbredning och säkerhetspåstående:

CICS-TX-Sec.jpg

Översikt över IMS-stöd

De optimerade lokala adaptrarna implementeras som ett externt delsystem till IMS. Användning stöds för meddelandebehandlingsprogram (MPP), program för batchmeddelandebehandling (BMP), IMS Fast Path (IFP) och Batch DL/I-applikationer.

Samtal från IMS till WAS använder ESAF (External Subsystem Attach Facility). Detta är samma gränssnitt som används av andra delsystem som DB2 eller MQ.

Anrop från WAS till den IMS-beroende regionen kan göras med OTMA eller direkt (det vill säga, program i IMS använder OLA API:er för att "värda en tjänst" enligt beskrivningen nedan). OTMA tillhandahåller OLA-transparens till IMS-applikationerna till en kostnad av viss overhead. Att använda OLA API:er i IMS-applikationen minskar omkostnaderna vilket resulterar i bättre prestanda och genomströmning.

WOLA-IMS-Overview.jpg

Programmerings-API:erna för IMS har samma format och syntax som introducerades ursprungligen. Men de har uppdaterats för att vara medvetna om IMS om de körs där och för att använda ESAF.

Dessutom måste ola.rar-filen som implementerar JCA-resursadaptern för WAS vara den som levereras med Fixpack 7.0.0.12 eller senare för att kunna användas med IMS. Metodparametrarna har uppdaterats för IMS-stödet och den uppdateringen görs tillgänglig för WAS genom att installera om ola.rar som följer med 7.0.0.12.

Följande bild sammanfattar WOLA IMS-stödet för transaktionsförmedling och säkerhetspåstående:

IMS-TX-Sec3.jpg

Programmeringsöverväganden

Inkommande till WAS z/OS

Det externa adressutrymmet får åtkomst till OLA-mekanismen via de medföljande gränssnittsmodulerna och dokumenterade API:er. Det finns 13 API:er för närvarande. De är kategoriserade nedan.

Java-program som körs i WAS z/OS-miljön som vill vara målet för en anrop utifrån måste implementera OLA-gränssnittet i en tillståndslös sessionsböna med hjälp av OLA-klassfilerna som tillhandahålls i stödet för utvecklingsverktyg.

Utgående från WAS z/OS

Ett Java-program som vill initiera ett utgående OLA-samtal kan implementeras som antingen en servlet eller EJB. Java-programmet kodar till den medföljande JCA-resursadaptern (ola.rar) med hjälp av klassfilerna som tillhandahålls i stödet för utvecklingsverktyg.

Externa adressutrymmen som är målet för det utgående samtalet måste vara i ett tillstånd redo att acceptera samtalet. Det finns två grundmodeller:

  • Om det externa adressutrymmet är CICS, har användaren möjlighet att använda den medföljande länkserveruppgiften för att agera som mottagande agent på uppdrag av befintliga CICS-programtillgångar. Länkserveruppgiften (BBO$ som standard) tar emot anropet och utfärdar en EXEC CICS LINK för programmet som heter interactionSpecImpl.setServiceName(). Inga ändringar av det befintliga CICS-programmet behövs förutsatt att det stöder antingen COMMAREA eller Channels/Containers.
  • Om den externa adressen är IMS kan anropet göras med IMS OTMA-gränssnittet (vilket inte innebär någon förändring av din IMS-applikation), eller direkt med OLA (vilket innebär att man använder OLA API:erna i IMS-programmet för att "värda en tjänst" ).
  • Om det externa adressutrymmet är något annat än CICS eller IMS, måste programmet "värd för en tjänst" med en av de medföljande API:erna. Det gör att programmet är redo att ta emot ett samtal från Java-programmet i WAS z/OS. När samtalet tas emot kan det sedan behandla begäran och ge ett svar tillbaka till Java-programmet i WAS z/OS

Synkrona och asynkrona operationer

API:erna stöder båda lägena. Synchronous ger en enklare programmeringsmodell eftersom programstyrning inte returneras till det anropande programmet förrän ett svar har mottagits. Asynkron ger arkitekten en möjlighet att bearbeta annat arbete utan att behöva vänta på ett svar som kommer tillbaka från en långvarig målprocess.

Modulär design

Det är möjligt att designa de OLA-specifika programmeringsartefakterna för att fungera som "bryggor" mellan OLA-gränssnittet och befintliga tillgångar. Det tjänar till att minimera påverkan på befintliga programmeringstillgångar och begränsar graden av "plattformslåsning".

  • Utgående till CICS – använd den medföljande länkserverimplementeringen; inga ändringar i dina CICS-program alls.
  • Inkommande till WAS—konstruera en EJB som tar OLA-anropet och sedan vänder och anropar den specificerade EJB. Om mål-EJB är i samma JVM kan det vara mycket effektivt. Om mål-EJB är i samma cell på samma LPAR används den tidigare nämnda "lokal kommunikations"-funktionen.

API:er

Det finns 13 API:er, kategoriserade i följande kategorier:

  • Allmän inställning och rivning -- BBOA1REG (registrera) och BBOA1URG (avregistrera)
  • Inbound Basic -- BBOA1INV (anropa med automatiskt få-svar)
  • Inkommande avancerad -- BBOA1CNG (hämta anslutning), BBOA1SRQ (skicka begäran), BBOA1RCL (hämta svarslängd), BBOA1GET (hämta meddelandedata), BBOA1CNR (släpp anslutning)
  • Outbound Basic -- BBOA1SRV (värd för en tjänst), BBOA1SRP (skicka svar)
  • Utgående avancerad -- BBOA1RCA (ta emot vid anslutning valfri), BBOA1RCS (motta vid anslutningsspecifik), BBOA1GET (hämta meddelandedata), BBOA1SRP (skicka svar) och BBOA1SRX (skicka ett undantag)

InfoCenter har en fullständig uppskrivning av var och en tillsammans med parameterlistor och returkod (RC) och orsakskoder (RSN). Sök på cdat_olaapis.

Illustrationer av vanliga API-mönster

En vanlig inkommande API-användningsmodell skulle vara:

Simple

I det här fallet används BBOA1REG API för att registrera sig i WebSphere Application Server for z/OS Daemon-gruppen (cellkortnamnet), och flera anrop av BBOA1INV används för att anropa mål-EJB. BBOA1INV är synkron så programkontrollen hålls kvar tills EJB returnerar ett svar. Detta API är användbart när det anropande programmet vet storleken på svarsmeddelandet i förväg. Om storleken på svarsmeddelandet är okänd vid tidpunkten för anropet skulle de mer primitiva API:erna (BBOA1SRQ (sänd begäran), BBOA1RCL (hämta svarslängd), BBOA1GET (hämta meddelandedata)) vara mer lämpliga.

När det anropande programmet fastställer att det har avslutat sitt arbete, använder det BBOA1URG för att avregistrera sig från Daemon-gruppen.

Om Java-målprogrammet har ett längre svarsintervall är en asynkron modell troligen bättre. Följande bild illustrerar hur ett asynkront anrop skulle göras med det som kallas det primitiva API:t: BBOA1SRQ med parameteruppsättningen async=1:

OLA More Advanced Inbound API.jpg

Som bilden illustrerar tillåter det asynkrona läget det icke-Java-programmet att få kontroll och göra annan bearbetning. Det innebär att man söker efter ett svar vid någon framtida tidpunkt. BBOA1RCL används för detta ändamål. I detta exempel utfärdas BBOA1RCL synkront (parameter async=0). Om ett svar är tillgängligt kommer BBOA1RCL att tillhandahålla längden och programkontrollen återgår till programmet. Om inget svar är tillgängligt håller BBOA1RCL programkontroll tills ett är tillgängligt. BBOA1RCL med async=1 returnerar x'FFFFFFFF' om inget svar är tillgängligt; programkontrollen återställs omedelbart.

Andra illustrationer för utgående kan hittas i WP101490-dokumentet som finns på IBM Techdocs webbplats.

Obs: Utgående från WAS till CICS skulle inte kräva API-kodning. I så fall skulle de medföljande BBO$/BBO#-länkservertransaktionerna göra denna bearbetning. Dessa länkservertransaktioner "värdar en tjänst" genom att använda de interna konstruktionerna som liknar BBOA1SRV API. Utgående till ett batchprogram skulle kräva användning av API:erna för att "värda en tjänst."

Transaktionalitet

De optimerade lokala adaptrarna stöder tvåfas commit-bearbetning (2PC) från CICS inkommande till WAS.

Med tillkomsten av underhåll 7.0.0.12 stöder Optimized Local-adaptrarna också tvåfas commit utgående från WAS till CICS. Före 7.0.0.12 var transaktionsstödet från WAS till CICS begränsat till "synkronisering vid retur."

För IMS gavs stöd för transaktionsförsäkran inkommande till WAS från IMS-beroende regioner i fixpack 8.0.0.4 och 8.5.0.1. Transaktionspåstående utgående från WAS till IMS över WOLA/OTMA tillhandahålls i fixpack 8.0.0.5.

Transaktionsspridning stöds inte inkommande eller utgående till batch, USS eller Airlines Line Control.

säkerhet

De optimerade lokala adaptrarna kan hävda identitet under följande omständigheter:

  • WAS --> CICS : Identiteten på WAS-tråden som används för att anropa WOLA API kan användas för att hävda identitet i CICS. För att göra detta måste WOLA CICS-länkservern användas och startas med parametern SEC=Y och CICS-regionen måste köras med SEC=YES och ID som länkserveruppgiften körs under måste ha SURROGAT SAF-behörighet för att starta transaktioner på uppdrag av det spridda användar-ID:t. Se IBM InfoCenter för mer information om detta.
  • WAS --> Batch, USS eller ALCS: inga försök att hävda identitet görs. Målprocessen körs under den identitet som användes när den startades.
  • CICS --> VAR: CICS kan hävda sitt region-ID eller applikationens användar-ID
  • Batch, USS eller ALCS: Den externa processen kommer att försöka hävda sin identitet i WAS z/OS.

Begränsningar

WAS z/OS optimerade lokala adaptrar kan endast användas inom en given LPAR. Det är en korsminnesmekanism och kan inte gå mellan LPAR eller utanför maskinen.

externa länkar


Hämtad från " https://en.wikipedia.org/w/index.php?title=WebSphere_Optimized_Local_Adapters&oldid=1085039902 "