I Tillæg B, Tilpasningsskema til DB2-kataloger vises de oplysninger, du skal indsamle. Det kan være en god idé at kopiere arbejdsarket og notere oplysninger om egne systemværdier derpå.
Du kan angive følgende oplysninger i nodekataloget:
Format: En streng på 1-8 tegn, der kan bestå af bogstaver, tal, nummertegn (#), snabel-a (@), dollartegn ($) og understregning (_). Første tegn må ikke være understregning eller et tal.
Hvis den eksterne vært er et DB2 til OS/390-system, kan værtsnavnet ses i DSNL004I-meddelelsen (DOMAIN=værtsnavn), når DDF (Distributed Data Facility) startes.
Hvis den eksterne vært er et DB2 til OS/390-system, er portnummeret defineret i BSDS (BootStrap Data Set) som PORT og vises også i DSNL004I-meddelelsen (TCPPORT=portnummer), når DDF (Distributed Data Facility) startes.
Bemærk: | Serveren definerer endnu en port, der benyttes til resynkronisering af tofase-commit-transaktioner over TCP/IP-forbindelser. DB2 Universal Database til OS/390 BSDS definerer f.eks. et portnummer (RESPORT), der kun skal benyttes til resynkronisering af indgående forbindelser til DB2 Universal Database til OS/390. Der skal ikke defineres et servicenavn til denne port. |
Du kan angive følgende oplysninger i DCS-kataloget:
Format: En streng på 1-8 tegn, der kan bestå af bogstaver, tal, nummertegn (#), snabel-a (@), dollartegn ($) og understregning (_). Første tegn må ikke være understregning eller et tal.
Du kan få fastslået LOCATION NAME ved at logge på TSO og afsende følgende SQL-forespørgsel vha. et af de tilgængelige forespørgselsværktøjer:
SELECT aktuel server FROM sysibm.sysdummy1
LOCATION NAME er desuden defineret i MVS/ESA BSDS (Boot Strap Data Set) og vises også i meddelelsen DSNL004I (LOCATION=placering), som afsendes, når DDF (Distributed Data Facility) startes.
Du kan få fastslået LOCATION NAME ved at logge på TSO og afsende følgende SQL-forespørgsel vha. et af de tilgængelige forespørgselsværktøjer:
SELECT aktuel server FROM sysibm.sysdummy1
LOCATION NAME er desuden defineret i BSDS (Boot Strap Data Set) og vises også i meddelelsen DSNL004I (LOCATION=placering), som afsendes, når DDF (Distributed Data Facility) startes.
Format: AR <applikations-requesternavn>
Standardværdien er DB2 Connect-applikations-requesteren.
SQL30000N SQL30040N SQL30050N SQL30051N SQL30053N SQL30060N SQL30070N SQL30071N SQL30072N SQL30073N SQL30074N SQL30090N
Når Disconnect-parameteren ,D ikke angives, afbrydes forbindelsen kun, når følgende SQLCODE-værdier returneres:
SQL30020N SQL30021N SQL30041N SQL30061N SQL30081N
Der findes en forklaring på koderne i Meddelelseshåndbog.
Bemærk: | Hvis DB2 Connect afbryder forbindelsen på grund af en fejl, udføres automatisk rollback. |
Applikationen vil modtage SQLCODE -30081, som angiver, at forbindelsen til serveren er afbrudt. Applikationen skal derefter oprette en ny forbindelse til værts- eller AS/400-databaseserveren for at få udført yderligere databaseforespørgsler. På andre platforme end AIX Version 4.1 og nyere versioner, SNA Server Version 3.1 og nyere versioner, OS/2, Windows NT og Windows 2000 vil DB2 Connect ikke automatisk afbryde forbindelsen, når en applikation, der bruger forbindelsen, modtager et interrupt.
Bemærk: | Funktionen understøttes for TCP/IP-forbindelser på alle platforme. Klienten kan lukke denne socket, men der kan være en udestående modtagelse af data, afhængigt af serverimplementationen. DB2 Universal Database til OS/390 benytter asynkrone socket-kald og kan derfor registrere en mistet forbindelse og udføre rollback af eventuelle igangværende SQL-sætninger. |
Der er også indført en ny profilvariabel (system eller registreringsdatabase) ved navn DB2SYSPLEX_SERVER. Den kan benyttes til at deaktivere SYSPLEX-støtte på arbejdsstationsniveau.
Antag, at følgende sætninger udstedes på DB2-kommandolinien (CLP):
catalog appc node cphnode remote cphcpic security program catalog dcs database cphdb1 as copnhgn catalog database cphdb1 as copnhgn1 at node cphnode authentication dcs
Databasealiaset copnhgn1 skal bruges til at få adgang til en værtsdatabase uden datoformatering, fordi der ikke er angivet en datomaske.
Med den nye datoformateringsfunktion kan du nu benytte nedenstående CLP-kommandoer. I dette tilfælde, hvor CLP benyttes, og parameterstrengen i sig selv omsluttes af dobbelte anførselstegn, skal LOCALDATE-værdien omsluttes af to par dobbelte anførselstegn. Bemærk også, at systemets escape-tegn "\" (omvendt skråstreg) bruges til at sikre, at de dobbelte anførselstegn bevares i LOCALDATE-angivelsen. Se også Angivelse af parameterstrengen.
catalog dcs database cphdb2 as copnhgn parms \",,,,,,LOCALDATE=\"\"YYYYMMDD\"\"\" catalog database cphdb2 as copnhgn2 at node cphnode authentication dcs
Databasealiaset "copnhgn2" giver adgang til samme værtsdatabase, men i dette tilfælde er der angivet en maske for datoformatet. Eksemplet viser, at masken for datoformat angives vha. nøgleordet LOCALDATE, og at det er den syvende positionsparameter i PARMS-feltet i en DCS-katalogindgang.
En gyldig datomaske forudsætter, at alle følgende betingelser er opfyldt:
Nedenfor er eksempler på gyldige datomasker:
"YYyyMmDd" - Der skelnes ikke mellem store og små Y'er, M'er og D'er "MM+DD+YYYY" - Masken må gerne være længere end 10 byte og indeholde andre tegn end Y, M og D "abcYY+MM" - Masken behøver ikke at indeholde en D-sekvens
Følgende datomasker er ugyldige:
"YYYYyMMDD" - ugyldig, der er 5 Y'er i en sekvens "YYYYMDDM" - ugyldig, der er 2 M-sekvenser
Der afsendes ikke en fejl, hvis en datomaske er ugyldig. Den ignoreres blot. At en datomaske er gyldig, betyder ikke, at den vil blive anvendt. En gyldig datomaske bruges kun til ændring af datoformat, hvis alle følgende betingelser er opfyldt:
I Ændring af MVS-kodeord vises dette eksempel på katalogisering af et DCS-databasekatalog vha. CHGPWD_SDN:
catalog dcs database db1 as dsn_db_1 parms ",,,,,,,CHGPWD_SDN=pempgm"
",,,,,,,,BIDI=xyz"
hvor xyz repræsenterer den CCSID, der skal anvendes i stedet for (se (BIDI_NOTE1)).
I Administration Guide er der en oversigt over, hvilke tovejs-CCSID'er der kan anvendes, og de tilsvarende strengtyper.
Der kræves følgende tovejsegenskaber til korrekt håndtering af tovejsdata på forskellige platforme:
Da standardværdier for forskellige platforme ikke er de samme, kan der opstå problemer, når DB2-data sendes fra én platform til en anden. F.eks. bruger Windows-platforme LOGICAL UNSHAPED-data, mens data på MVS og i OS/390 som regel er i formatet SHAPED VISUAL. Derfor bliver data, der sendes fra DB2 til MVS eller OS/390 til DB2 Connect i Windows, ikke vist korrekt, hvis der ikke er støtte til tovejsegenskaber.
Når der udveksles data mellem DB2 Connect og en database på en server, er det oftest modtageren, der udfører konvertering af de indgående data. Samme fremgangsmåde kan almindeligvis også anvendes til konvertering af layout for tovejssprog - ud over den almindelige tegntabelkonvertering. Aktuelt er der dog ikke noget DB2-produkt til værtssystemer, der støtter tovejsspecifikke CCSID'er eller konvertering af layout for tovejssprog. Derfor er DB2 Connect udvidet med en valgfri funktion til konvertering af layout af data på tovejssprog, som skal sendes til serverdatabasen, og data, der modtages fra serverdatabasen.
Serverdatabasens CCSID'er for tovejssprog skal tilsidesættes (se (BIDI_NOTE2)), før DB2 Connect kan konvertere layout af udgående data på tovejssprog til en serverdatabase. Det gøres vha. parameteren BIDI i feltet PARMS i DCS-databasekatalogindgangen for serverdatabasen.
Funktionen illustreres bedst med et eksempel.
En hebraisk DB2-klient kører CCSID 62213 (tovejsstrengtype 5) og ønsker adgang til en DB2-database på et værtssystem, der kører CCSID 424 (tovejsstrengtype 4). Du er imidlertid klar over, at data i DB2-databasen på værtssystemet i stedet er baseret på CCSID 8616 (tovejsstrengtype 6).
Dette indebærer to problemer. Det første problem er, at DB2-databasen på værtssystemet ikke kender forskel på tovejsstrengtyperne for CCSID 424 og 8616. Det andet problem er, at DB2-databasen på værtssystemet ikke genkender DB2-klientens CCSID 62213. Den støtter kun CCSID 862, som er baseret på samme tegntabel som CCSID 62213.
Du skal sikre dig, at data, der sendes til DB2-databasen på værtssystemet har tovejsstrengformatet type 6 til at begynde med. Du skal ligeledes angive over for DB2 Connect, at der skal udføres konvertering af layout for data på tovejssprog, der modtages fra DB2-databasen på værtssystemet. Du skal anvende følgende katalogisering for DB2-databasen på værtssystemet:
catalog dcs database nydb1 as TELAVIV parms ",,,,,,,,BIDI=8616"
Dermed får DB2 Connect besked om at erstatte CCSID 424 i DB2-databasen på værtssystemet med 8616. Der indgår følgende processer i erstatningen:
Bemærkninger:
Hvis en bestemt tovejs-CCSID giver problemer, som ikke kan afhjælpes ved at følge ovenstående anbefalinger, bør du sætte systemvariablen eller registerværdien DB2BIDI til NO.
Nedenfor vises eksempler på parameterstrenge.
Du kan f.eks. angive følgende strenge, hvor "\" (omvendt skråstreg) er styresystemets escape-tegn:
I AIX:
NOMAP /u/bruger/sqllib/map/dcs1new.map,D ,D ,,INTERRUPT_ENABLED NOMAP,D,INTERRUPT_ENABLED,,,SYSPLEX,LOCALDATE=\"\"YYMMDD\"\",,
I OS/2, Windows NT eller Windows 2000:
NOMAP d:\sqllib\map\dcs1new.map,D ,,INTERRUPT_ENABLED NOMAP,D,INTERRUPT_ENABLED,,,SYSPLEX,LOCALDATE=\"\"YYMMDD\"\",,
Alternativt kan du acceptere standardværdierne ved ikke at angive en parameterstreng.
Bemærk: | Da det er nødvendigt at angive to par dobbelte anførselstegn omkring
LOCALDATE-masken i parameterstrengen, skal du benytte styresystemets
escape-tegn ("\" (omvendt skråstreg)) som i følgende eksempel:
db2 catalog dcs db x as y parms \",,,,,,LOCALDATE=\"\"YYMMDD\"\"\"Resultatet er følgende indgang i DCS-kataloget: Registrering af DCS 1: Lokalt databasenavn = X Måldatabasenavn = Y Navn på applikations-requester = DCS-parametre = ,,,,,,LOCALDATE="YYMMDD" Kommentar = Versionsnummer på DCS-katalog = 0x0100 |
Du kan angive følgende oplysninger i systemdatabasekataloget:
Format: En streng på 1-8 tegn, der kan bestå af bogstaver, tal, nummertegn (#), snabel-a (@), dollartegn ($) og understregning (_). Første tegn må ikke være understregning eller et tal.
For hver database skal der defineres mindst én indgang i hver af de tre kataloger (nodekatalog, DCS-katalog og systemdatabasekatalog). I visse tilfælde kan der være behov for at definere flere indgange for en database.
Du vil måske deaktivere omdefinition af SQLCODE-værdier for applikationer, der er porteret fra værts- eller AS/400-databaseserveren, og benytte standardfilen til omdefinition af koderne for applikationer, der er udviklet til client/server-miljøet. Det gøres på følgende måde:
Begge aliaser refererer til samme database, den ene med omdefinition af SQLCODE-værdien, den anden uden.