DB2 za VM izvaja podporo za zahtevnik aplikacij DRDA kot integralni del vmesnika sredstev, ki se nahaja na navideznem računalniku končnega uporabnika z aplikacijo. Podporo za zahtevnik aplikacij lahko uporabite tudi, če navidezni računalnik lokalnega upravljalniki baz podatkov ni aktiven. Podporo za zahtevnik aplikacij DRDA lahko aktivirate tako, da zaženete SQLINIT EXEC z možnostjo protocol(auto) ali protocol(drda) (glejte Možnosti za vnaprejšnjo obdelavo ali izvajanje aplikacije).
Če DB2 za VM deluje kot zahtevnik aplikacij, lahko vzpostavi povezavo s strežnikom aplikacij DB2 za VM ali s katerimkoli strežnikom, ki podpira arhitekturo DRDA. Če želite, da bo zahtevnik aplikacij DB2 za VM omogočal dostop do porazdeljene baze podatkov, morate vedeti, kako se naredi naslednje:
Velik del obdelave v okolju porazdeljene baze podatkov zahteva izmenjavo sporočil z drugimi mesti v omrežju. Za pravilno izvedbo tega postopka naredite naslednje:
Zahtevnik aplikacij DB2 za VM in strežnik aplikacij DB2 za VM sta neodvisna eden od drugega. Zahtevnik aplikacij DB2 za VM usmerja povezovalne zahteve neposredno na lokalne ali oddaljene strežnike aplikacij, vendar pa sebe ne definira kot cilj vhodnih povezovalnih zahtev. Vhodne povezovalne zahteve lahko sprejme (ali zavrne) samo strežnik aplikacij DB2 za VM. Zato zahtevnik aplikacij DB2 za VM ne določi RDB_NAME in TPN za samega sebe, kot to naredi DB2 Universal Database za OS/390.
Zahtevnik aplikacij DB2 za VM definirajte za omrežje SNA takole:
Zahtevnik aplikacij je imena prehodov (na primer imena LU) definiral za usmerjanje svojih izhodnih zahtev v omrežje. Slika 30 kaže zgled za to. Ti stavki so na navideznem računalniku VTAM. Ko se zažene VTAM, se prehodi določijo za omrežje, vendar se ne aktivirajo, dokler se ne zažene nadzorni navidezni računalnik AVS. Vsak navidezni računalnik AVS lahko definira več prehodov na gostitelju VM.
Slika 30. Zgled definicije prehoda AVS
VBUILD TYPE=APPL ************************************************************* * * * Definicija prehoda za sistem Toronto DB2 za VM * * * ************************************************************* TORGATE APPL APPC=YES, X AUTHEXIT=YES, X AUTOSES=1, X DMINWNL=10, X DMINWNR=10, X DSESLIM=20, X EAS=9999, X MAXPVT=100K, X MODETAB=RDBMODES, X PARSESS=YES, X SECACPT=ALREADYV, X SYNCLVL=SYNCPT, X VPACING=2 |
Naslednji seznam opisuje ključne besede stavka VTAM APPL, ki se nanašajo na teme tega priročnika. (Stavek VTAM APPL podpira veliko več ključnih besed, kot smo jih opisali).
DB2 za VM pri izbiri vrednosti za ključno besedo VERIFY ne določa nobene omejitve, vendar nanjo lahko vpliva različica VTAM, ki jo izvajate. V neoverjenem omrežju DB2 za VM priporoča kodiranje VERIFY=REQUIRED. Če izberete VERIFY=OPTIONAL, VTAM izvede preverjanje LU-ja partnerja samo za tiste partnerje, ki nudijo podporo. VERIFY=REQUIRED povzroči, da VTAM zavrne partnerje, ki ne morejo izvesti preverjanja LU-ja partnerja.
Omogočanje prehoda se izvede na navideznem računalniku AVS, ki deluje na enakem gostitelju (ali na drugih gostiteljih znotraj enake zbirke TSAF) kot zahtevnik aplikacij DB2 za VM. V profil delovne postaje AVS vključite ukaz AGW ACTIVATE GATEWAY GLOBAL ali ta ukaz izdajte interaktivno na ukazni mizi delovne postaje AVS, da boste samodejno omogočili prehod pri vsakem zagonu AVS.
Zagotovite, da je vrednost MAXCONN v imeniku CP delovne postaje prehoda AVS dovolj velika, da lahko podpira skupno število zahtevanih sej.
Na navideznem računalniku AVS izdajte ukaz AGW DEACTIVE GATEWAY, da boste onemogočili prehod. Definicija prehoda ostane. Prehod lahko kadarkoli znova aktivirate z ukazom AGW ACTIVATE GATEWAY GLOBAL.
Informacije o obliki ukazov AVS lahko najdete v priročniku VM/ESA Connectivity Planning, Administration and Operation .
NETID gostitelja (ali drugih gostiteljev znotraj enake zbirke TSAF), na katerem je zahtevnik aplikacij, posreduje VTAM, ko zahteva vstopi v omrežje. NETID je shranjen v datoteki CMS SNA NETID in se nahaja na produkcijskem disku DB2 za VM, do katerega dostopi zahtevnik aplikacij. Odjemalec aplikacij uporablja ta NETID za izdelavo LUWID, ki potuje z vsakim pogovorom.
Oddaljene sisteme morate definirati tako, da registrirate imena LU, ki VTAM omogočajo, da poišče želen omrežni cilj. Ko se zažene AVS, določi globalna imena prehodov (imena LU), ki so na voljo za usmerjanje zahtev SQL iz omrežja v VTAM. Ime prehoda mora biti enkratno v naboru imen LU, ki jih prepozna lokalni sistem VTAM, da bodo vhodne in izhodne zahteve usmerjene na pravilno ime LU. To je najboljši način za zagotavljanje enkratnih imen prehodov v celotnem omrežju uporabnika, poleg tega pa tudi poenostavlja postopek definiranja sredstev VTAM.
Ko aplikacija DB2 za VM zahteva podatke iz oddaljenega sistema, DB2 za VM v komunikacijskem imeniku CMS poišče naslednje informacije, povezane z oddaljenim sistemom:
Komunikacijski imenik CMS je datoteka CMS z imeni tipov datotek, ki jo izdela in upravlja skrbnik sistema DB2 za VM. Kot skrbnik lahko za izdelavo te datotek in za dodajanje želenih postavk, ki bodo določale vse možne partnerje DRDA, uporabite XEDIT. Vsaka postavka v imeniku predstavlja nabor oznak in z njimi povezane vrednosti. Slika 31 kaže vzorčno postavko. Pri iskanju se iskalni ključ primerja z vrednostjo oznake :dbname vsake postavke v datoteki, dokler ni najdeno ujemanje ali dokler ni dosežen konec datoteke. Slika 31 kaže zgled za vodjo prodaje, ki želi izdelati mesečno poročilo o prodaji za podružnico v Montrealu tako, da do podatkov dostopi oddaljeno iz baze podatkov MONTREAL_SALES.
Slika 31. Vzorčna postavka v komunikacijskem imeniku CMS
+--------------------------------------------------------------------------------+ | SCOMDIR NAMES A1 V 132 Trunc=132 Size=10 Line=1 Col=1 Alt=8 | |====> | |00001 :nick.MTLSALES | |00002 :tpn.SALES | |00003 :luname.TORGATE MTLGATE | |00004 :modename.BATCH | |00005 :security.PGM | |00006 :userid.SALESMGR | |00007 :password.GREATMTH | |00008 :dbname.MONTREAL_SALES | |00009 | +--------------------------------------------------------------------------------+ |
Oznaka :tpn določa ime transakcijskega programa, ki aktivira strežnik aplikacij. Prvi del oznake :luname določa prehod AVS (lokalni LU), ki se uporablja za pridobivanje dostopa do omrežja SNA. Drugi del določa ime oddaljenega LU. Oznaka :modename določa način VTAM, ki definira značilnosti sej, dodeljenih med lokalnimi in oddaljenimi LU-ji. Zgled za te značilnosti so velikost enote zahteve (RU), krmiljenje takta in razred storitve (COS). Oznaka :security kaže na raven zaščite, ki bo uporabljena v pogovoru, ki zahtevnik aplikacij povezuje s strežnikom aplikacij.
Komunikacijski imenik CMS je na javnem sistemskem disku, do katerega imajo dostop vsi zahtevniki aplikacij v določenem sistemu VM. Uporabijo ga lahko vsi programi ali izdelki, ki zahtevajo oddaljeni dostop prek VTAM.
Dostopite lahko do dveh ravni komunikacijskega imenika CMS: do sistemske ravni in do uporabniške ravni. Tako lahko na primer na javnem sistemskem disku, do katerega lahko dostopajo vsi zahtevniki aplikacij v določenem sistemu VM, izdelate imenik na ravni sistema. Izdelate lahko tudi lasten imenik na ravni uporabnika, ki bo prevladal nad obstoječimi postavkami ali vpeljete nove postavke, ki jih ni v imeniku na ravni sistema. Pri iskanju bo najprej preiskan imenik na ravni uporabnika, če pa iskanje ne uspe, se bo nadaljevalo v imeniku na ravni sistema. Imenik na ravni sistema je razširitev imenika na ravni uporabnika; preiskan bo samo, če vrednosti niso najdene v imeniku na ravni uporabnika.
Oba izmed teh imenikov sta določena za aplikacijo in ju aktivirate z ukazom CMS SET COMDIR. Tako lahko na primer z naslednjim zaporedjem ukazov določite imenik na ravni sistema in na ravni uporabnika (na minidiskih S oziroma A), in določite, naj se za iskanje aktivira samo imenik na ravni sistema:
SET COMDIR FILE SYSTEM SCOMDIR NAMES S SET COMDIR FILE USER UCOMDIR NAMES A SET COMDIR OFF USER
Komunikacijski imenik CMS je podrobno opisan v VM/ESA Connectivity Planning, Administration and Operation. Ukaz CMS SET COMDIR je opisan v VM/ESA CMS Command Reference.
V okolju VM izvaja upravljanje komunikacij kombinacija komponent. Komponente, vključene v komunikacije med nepodobnimi sistemi DRDA, so APPC/VM, komunikacijski imenik CMS, TSAF, AVS in VTAM.
APPC/VM je API na ravni zbirnika LU 6.2, ki ga zahtevnik aplikacij DB2 za VM uporablja za zahtevanje komunikacijskih storitev. Komunikacijski imenik CMS posreduje informacije o usmerjanju in zaščiti v porazdeljenem sistemu partnerja. AVS aktivira prehod in prevede izhodne tokove APPC/VM v tokove APPC/VTAM, vhodne tokove APPC/VTAM pa v tokove APPC/VM.
APPC/VM, TSAF in AVS se za usmerjanje zahtev pravilnemu partnerju DRDA zanašajo na komunikacijski imenik CMS, VTAM in *IDENT.
Če želite, da bo VTAM komuniciral z aplikacijami partnerja, ki so določene v komunikacijskem imeniku CMS, morate podati naslednje informacije:
Če zahtevnik aplikacij za komuniciranje z oddaljenim strežnikom aplikacij uporablja AVS, se vzpostavi povezava. Če je zaradi te povezave omejitev vzpostavljene seje presežena, AVS postavi povezavo v čakajoče stanje, dokler seja ne postane na voljo. Ko je seja na voljo, ji AVS dodeli čakajočo povezavo, nadzor pa je vrnjen uporabniški aplikaciji. Če se želite izogniti tej situaciji, načrtujte največjo možno uporabo tako, da povečate omejitev seje in omogočite nekaj dodatnih povezav. Zagotovite, da je vrednost MAXCONN v imeniku CP delovne postaje AVS dovolj velika, da lahko podpira največjo možno uporabo za povezave APPC/VM.
Postavke, ki jih definirate v tabeli načinov VTAM, podajajo velikosti enot zahtev (RU) in števce za krmiljenje takta. Če teh vrednosti ne definirate pravilno, lahko to negativno vpliva na vse aplikacije VTAM.
Ko izberete velikosti enot zahtev (RU), omejitve sej in števce za krmiljenje takta, razmislite, kakšen vpliv imajo lahko te vrednosti na obstoječe omrežje SNA. Ko namestite nov sistem porazdeljene baze podatkov, preglejte naslednje postavke:
Če podate parameter NCP MAXBFRU, izberite vrednost, ki lahko obravnava velikost RU plus 29 bajtov. Za NCP parameter MAXBFRU definira število V/I vmesnih pomnilnikov VTAM, v katerih lahko hranite PIU. Če izberete velikost vmesnega pomnilnika IOBUF 441, MAXBFRU=10 pravilno obdela 4-kilobajtni RU, ker je vrednost 10*441 večja od 4096+29.
Zahtevnik aplikacij DB2 za VM morda nima nameščene podpore za DRDA. Za pripravo zahtevnika aplikacij DB2 za VM za komunikacije DRDA storite naslednje:
Za podrobnejše informacije preberite priročnik DB2 for VM System Administration.
Če oddaljeni sistem na zahtevo aplikacije SQL izvaja obdelavo porazdeljene baze podatkov, mora zadovoljiti zahtevam za zaščito, ki jih določajo zahtevnik aplikacij, strežnik aplikacij in omrežje, ki ju povezuje. Te zahteve lahko razdelimo v eno ali več izmed naslednjih kategorij:
V SQL in v LU 6.2 so končnim uporabnikom dodeljeni ID-ji, sestavljeni iz 1 do 8 znakov. Ta ID uporabnika mora biti enkraten v določenem operacijskem sistemu, ni pa nujno enkraten tudi v celotnem omrežju SNA. Tako lahko na primer obstaja uporabnik z imenom JONES v sistemu TORONTO in drug uporabnik z enakim imenom v sistemu MONTREAL. Če sta ta dva uporabnika ena in ista oseba, navzkrižja ni. Če pa uporabnik JONES iz sistema TORONTO ni enaka oseba kot uporabnik JONES iz sistema MONTREAL, omrežje SNA (in posledično tudi sistem porazdeljene baze podatkov znotraj tega omrežja) ne more razločevati med njima. Če ne preprečite te situacije, lahko uporabnik JONES iz sistema TORONTO uporablja pooblastila, ki so dodeljena uporabniku JONES iz sistema MONTREAL in obratno.
Za odpravljanje navzkrižij pri poimenovanju je v DB2 za VM vključena podpora za prevod imen končnih uporabnikov. Vendar pa sistem ne uveljavi prevoda ID-jev uporabnikov. Če je zahtevan sistemsko uveljavljen prevod, morate zagotoviti, da se na strežniku aplikacij izvede pravilen vhodni prevod.
Izhodni prevod se izvede z uporabo komunikacijskega imenika CMS. Postavka v komunikacijskem imeniku CMS mora podajati :security.PGM. V tem primeru bodo ustrezne vrednosti iz oznak :userid in :password posredovane oddaljenemu mestu (strežniku aplikacij) v povezovalni zahtevi.
Če izdelate postavko kot kaže slika 32 na strani 118, bo uporabnik z ID-jem JONES v lokalnem sistemu (TORONTO) preslikan v ID uporabnika JONEST, ko bo vzpostavil povezavo z strežnikom aplikacij MONTREAL_SALES_DB v sistemu MONTREAL. Na ta način boste odstranili navzkrižja v ID-ju uporabnika.
Slika 32. Prevod izhodnega imena
+--------------------------------------------------------------------------------+ | UCOMDIR NAMES A1 V 132 Trunc=132 Size=10 Line=1 Col=1 Alt=8 | |====> | |00001 :nick.MTLSALES | |00002 :tpn.SALES | |00003 :luname.TORLU MTLGATE | |00004 :modename.BATCH | |00005 :security.PGM | |00006 :userid.JONEST | |00007 :password.JONESPW | |00008 :dbname.MONTREAL_SALES_DB | |00009 | +--------------------------------------------------------------------------------+ |
Ko izberete ime končnega uporabnika, ki predstavlja zahtevnik aplikacij na oddaljenem mestu (strežnik aplikacij), mora zahtevnik aplikacij podati potrebne informacije o zaščiti omrežja LU 6.2. LU 6.2 nudi tri glavne načine za zaščito omrežja:
Ker je strežnik aplikacij odgovoren za upravljanje sredstev baze podatkov, tudi določa, katere načine za zaščito omrežja mora nuditi zahtevnik aplikacij. Zahteve za zaščito strežnika aplikacij morate zabeležiti v komunikacijskem imeniku zahtevnika aplikacij tako, da v oznaki :security nastavite ustrezno vrednost.
Možnosti za zaščito na ravni pogovora SNA, ki jih podpira DRDA, so naslednje:
DB2 za VM ne podpira šifriranja gesel. Geslo lahko podate v oznaki :password ali ga shranite v postavki imenika CP končnega uporabnika tako, da uporabite stavek imenika APPCPASS. Uporabo stavka APPCPASS priporočamo, če želite povečati zaščito z geslom. Če v postavki komunikacijskega imenika CMS ne podate gesla, bo stavek APPCPASS poiskan v postavki imenika uporabniškega sistema (VM).
VM nudi stavek APPCPASS, s katerim lahko povečate zaščito ID-ja uporabnika in gesla, ki ju zahtevnik aplikacij uporabi za vzpostavitev povezave s strežnikom aplikacij. APPCPASS je prožen, saj omogoča, da informacije o zaščiti shranite na enega izmed naslednjih načinov:
Slika 33 kaže primer, v katerem je ID uporabnika shranjen v komunikacijskem imeniku uporabnika, geslo pa v postavki imenika VM uporabnika. V postavki komunikacijskega imenika je ID uporabnika nastavljen na MTLSOU, geslo pa ni nastavljeno. Geslo je shranjeno v postavki imenika VM uporabnika.
Slika 33. Zgled postavke komunikacijskega imenika brez gesla
+--------------------------------------------------------------------------------+ | UCOMDIR NAMES A1 V 132 Trunc=132 Size=8 Line=1 Col=1 Alt=8 | |====> | |00001 :nick.MTLSALES | |00002 :tpn.SALES | |00003 :luname.TORGATE MTLGATE | |00004 :modename.BATCH | |00005 :security.PGM | |00006 :userid.MTLSOU | |00007 :password. | |00008 :dbname.MONTREAL_SALES_DB | |00009 | +--------------------------------------------------------------------------------+ |
Ko APPC/VM inicializira povezavo med zahtevnikom in strežnikom aplikacij z uporabo pogovora SECURITY=PGM, prebere oznaki :userid in :password ter ju posreduje strežniku aplikacij. Če je ena od oznak ali če sta obe oznaki nastavljeni na prazno polje, manjkajoče informacije poišče v postavki imenika VM uporabnika. V tem primeru mora v postavki imenika VM obstajati takšen stavek APPCPASS:
APPCPASS TORGATE MTLGATE MTLSOU Q6VBN8XP
Ta stavek APPC/VM pove, da mora uporabnik (zahtevnik aplikacij), ki zahteva povezavo prek (lokalnega) prehoda AVS TORGATE, partnerskega LU-ja z imenom MTLGATE in ID-ja uporabnika MTLSOU, strežniku aplikacij poslati geslo Q6VBN8XP. Uporabnik je na strežniku aplikacij prepoznan po teh identifikacijah.
Postavitev stavka APPCPASS v imenik VM ni naloga končnega uporabnika. Končni uporabnik mora to zahtevati od programerja sistemov VM.
Za dodatne informacije o zaščiti na ravni komunikacije in stavku APPCPASS preberite priročnik VM/ESA Connectivity Planning, Administration, and Operation.
Kot del celotne zaščite porazdeljene baze podatkov v DRDA lahko zahtevnik aplikacij nadzoruje, kateri končni uporabniki lahko opravljajo zahteve porazdeljene baze podatkov. V DB2 za VM lahko zahtevnik aplikacij sodeluje v zaščiti porazdeljene baze podatkov na tri načine:
Zunanji zaščitni podsistem v sistemih VM je običajno na voljo prek RACF ali prek enakovrednih izdelkov, ki nudijo združljivost vmesnika z RACF. Zahtevnik aplikacij DB2 za VM ne komunicira neposredno z zunanjim zaščitnim podsistemom. Zunanji zaščitni podsistem se ne uporablja za posredovanje gesel za zaščito na ravni pogovora. Če izberete uporabo zaščite na ravni seje, VTAM pokliče zunanji zaščitni podsistem, ki med preverjanjem LU-ja partnerja preveri identiteto oddaljenega imena LU.
Zahtevnik aplikacij mora imeti pravilne privzete vrednosti za CHARNAME in CCSID. Z izbiro pravilnih vrednosti zagotovite integriteto predstavitve znakovnih podatkov in zmanjšate dodatno obremenitev, povezano s pretvorbo CCSID.
Če na primer zahtevnik aplikacij DB2 za VM izdelate s kodno stranjo 37 in z naborom znakov 697(CP/CS 37/697) za znake US ENGLISH, mora zahtevnik aplikacij nastaviti privzeti CHARNAME na ENGLISH. To je zato, ker CP/CS 37/697 ustreza CCSID 37, ki ustreza CHARNAME ENGLISH.
Privzeti CHARNAME na novo nameščenih ali preseljenih sistemov je INTERNATIONAL, CCSID pa je 500. Vendar pa ta privzetek najbrž ni pravilen za vašo namestitev. Za prikaz vrednosti trenutnih privzetih CCSID-ov uporabite naslednji ukaz:
SQLINIT QUERY
Pravilna vrednost CCSID za zahtevnik aplikacij je lahko vrednost, ki je ne podpirajo pretvorne tabele na strežniku aplikacij. V tem primeru lahko povezavo vzpostavite takole:
Zahtevnik aplikacij uporablja krmilnik, definiran s CP/CS 37/697. Strežnik aplikacij ne podpira pretvorbe iz CCSID 37, podpira pa pretvorbo iz CCSID 285 (to je CHARNAME UK-ENGLISH za SQL/DS).
Če zahtevnik aplikacij spremenite tako, da bo uporabljal privzeti CHARNAME UK-ENGLISH (in CCSID 285), integriteta podatkov ne bo ohranjena. Na primer, kjer strežnik aplikacij prikaže angleški znak za funt (Â) zahtevnik aplikacij prikaže znak za dolar ($). Do razlik lahko pride tudi pri drugih znakih.
Če želite spremeniti vrednost CCSID zahtevnika aplikacij DB2 za VM, morate podati parameter CHARNAME SQLINIT EXEC. Za dodatne informacije preglejte priročnik DB2 za VM System Administration .
Pravilna vrednost CCSID za strežnik aplikacij je lahko vrednost, ki je ne podpirajo pretvorne tabele na zahtevniku aplikacij. V tem primeru lahko povezavo vzpostavite takole:
Naslednji potrditveni seznam povzema korake, ki jih morate opraviti, če želite zahtevnik aplikacij DRDA omogočiti za komunikacije DRDA, začenši s predpostavko, da je sistem VM nameščen z ACF/VTAM kot načinom za dostop do teleobdelave, in da so definicije VTAM, potrebne za komuniciranje z oddaljenimi sistemi, kot so na primer definicije NCP, končane.