Tillegg B, Skjema for katalogtilpasning viser hvilke opplysningene du må samle inn. Det kan være nyttig å ta en kopi av skjemaet og oppgi systemverdiene dine.
Du kan oppgi følgende opplysninger i nodekatalogen:
Format: 1-8 alfanumeriske enkeltbytetegn, inkludert nummertegnet (#), krøllalfa (@), dollartegnet ($) og understreking (_). Det kan ikke starte med en understreking eller et tall.
For DB2 for OS/390-fjernverter vises vertsnavnet i DSNL004I-meldingen (DOMAIN=vertsnavn) når DDF (Distributed Data Facility) blir startet.
For DB2 for OS/390-fjernverter blir portnummeret definert i BSDS (Boot Strap Data Set) som PORT og i DSNL004I-meldingen (TCPPORT=portnummer) når DDF (Distributed Data Facility) blir startet.
Merk: | Tjeneren tildeler en annen port, som blir brukt til resynkroniseringsoperasjoner med tofaseiverksetting over TCP/IP-tilkoblinger. BSDS (Boot Strap Data set) for DB2 Universal Database for OS/390 tildeler for eksempel et portnummer (RESPORT) som bare skal brukes til resynkronisering for innkommende tilkoblinger til DB2 Universal Database for OS/390. Det er ikke nødvendig å definere noe tjenestenavn. |
Du kan oppgi følgende opplysninger i DCS-katalogen:
Format: 1-8 alfanumeriske enkeltbytetegn, inkludert nummertegnet (#), krøllalfa (@), dollartegnet ($) og understreking (_). Det kan ikke starte med en understreking eller et tall.
Du kan finne LOCATION NAME ved å logge deg på TSO og utføre denne SQL-spørringen ved hjelp av et av de tilgjengelige spørreverktøyene:
select current server from sysibm.sysdummy1
LOCATION NAME er også definert i MVS/ESA BSDS (Boot Strap Data Set) og i DSNL004I-meldingen (LOCATION=plassering), som blir skrevet når DDF (Distributed Data Facility) blir startet.
Du kan finne LOCATION NAME ved å logge deg på TSO og utføre denne SQL-spørringen ved hjelp av et av de tilgjengelige spørreverktøyene:
select current server from sysibm.sysdummy1
LOCATION NAME er også definert i BSDS (Boot Strap Data Set) og i DSNL004I-meldingen (LOCATION=plassering), som blir skrevet når DDF (Distributed Data Facility) blir startet.
Format: AR <applikasjonsklientnavn>
Standardverdien er DB2 Connect-applikasjonsklienten.
SQL30000N SQL30040N SQL30050N SQL30051N SQL30053N SQL30060N SQL30070N SQL30071N SQL30072N SQL30073N SQL30074N SQL30090N
Hvis frakoblingsparameteren ,D ikke er oppgitt, blir det bare utført en frakobling når disse SQLCODE-verdiene blir returnert:
SQL30020N SQL30021N SQL30041N SQL30061N SQL30081N
Du finner forklaringer på disse kodene i Meldinger.
Merk: | Hvis DB2 Connect blir frakoblet på grunn av en feil, blir det automatisk utført en tilbakestilling. |
Applikasjonen mottar sqlcode (-30081), som angir at tilkoblingen til tjeneren ble avsluttet. Applikasjonen må deretter opprette en ny tilkobling til verts- eller AS/400-databasetjeneren før den kan behandle flere databaseforespørsler. På andre plattformer enn AIX V4.1 og nyere, SNA Server V3.1 og nyere, OS/2, Windows NT og Windows 2000, støtter ikke DB2 Connect alternativet for automatisk frakobling når en applikasjon som bruker det, mottar en avbruddsforespørsel.
Merk: | Denne støtten fungerer for TCP/IP-tilkoblinger på alle plattformer. Klienten kan slå av kontakten (socket) men det kan være utestående mottak, avhengig av tjenerimplementeringen. DB2 Universal Database for OS/390 bruker asynkrone kontaktkall (socket call) og kan derfor finne tilkoblingsbruddet og tilbakestille eventuelle tidkrevende SQL-setninger som blir utført. |
Det er også introdusert en ny profilvariabel (system eller register) kalt DB2SYSPLEX_SERVER, som kan brukes til å deaktivere SYSPLEX-støtten på arbeidsstasjonsnivå.
Tenk deg at du utsteder disse setningene fra kommandolinjebehandleren (CLP):
catalog appc node nynode remote nycpic security program catalog dcs database nydb1 as new_york catalog database nydb1 as newyork1 at node nynode authentication dcs
Databasekallenavnet newyork1 blir brukt for å få tilgang til en vertsdatabase uten datotransformering siden det ikke er oppgitt noen datomaske.
Med den nye datoformateringsstøtten kan du imidlertid bruke CLP-kommandoene nedenfor. Siden kommandolinjebehandleren (CLP) blir brukt i dette tilfellet, og siden parameterstrengen blir oppgitt med doble anførselstegn, må LOCALDATE-verdien oppgis med to par doble anførselstegn. Legg merke til bruken av operativsystemskiftetegnet "\" (omvendt skråstrek) for å sikre at de doble anførselstegnene ikke blir fjernet fra LOCALDATE-spesifikasjonen. Se også Oppgi parameterstrengen.
catalog dcs database nydb2 as new_york parms \",,,,,,LOCALDATE=\"\"YYYYMMDD\"\"\" catalog database nydb2 as newyork2 at node nynode authentication dcs
Databasekallenavnet "newyork2" gir deg tilgang til den samme vertsdatabasen, men den har i tillegg en datoformatmaske oppgitt. Dette eksempelet illustrerer at datoformatmasken blir oppgitt ved hjelp av nøkkelordet LOCALDATE. Dette er den sjuende posisjonsavhengige parameteren i PARMS-feltet for en DCS-katalogpost.
For at datomasken skal være gyldig, må ALLE følgende betingelser oppfylles:
Alle eksemplene nedenfor er for eksempel gyldige datomasker:
"YYyyMmDd" - Y, M og D skiller ikke mellom store og små bokstaver "MM+DD+YYYY" - OK å ha en maske som er på mer enn 10 byte og å ha andre tegn enn Y, M og D i masken. "abcYY+MM" - OK ikke å ha en sekvens med D-er.
Begge eksemplene nedenfor er ugyldige datomasker:
"YYYYyMMDD" - ugyldig fordi det er 5 Y-er i sekvensen "YYYYMDDM" - ugyldig fordi det er 2 sekvenser med M-er
Hvis en datoformatmaske er ugyldig, blir det ikke gitt noen feilmeldinger. Den blir bare oversett. Selv om en datomaske er gyldig betyr det heller ikke at den blir brukt. Datoformattransformering basert på en gyldig datomaske blir utført bare hvis ALLE følgende betingelser oppfylles:
I Endre MVS-passordet ser du et eksempel på hvordan du katalogiserer en dcs-databasekatalog ved hjelp av CHGPWD_SDN:
catalog dcs database db1 as dsn_db_1 parms ",,,,,,,CHGPWD_SDN=pempgm"
",,,,,,,,BIDI=xyz"
der xyz representerer CCSID-overstyringen (se (BIDI_NOTE1)).
Du finner en liste over hvilke toveise CCSIDer som er støttet, og de tilhørende strengtypene i Administration Guide.
Disse toveisattributtene er nødvendige for å oppnå riktig behandling av toveisdata på ulike plattformer:
Siden standardverdiene varierer fra plattform til plattform, oppstår det problemer når det blir sendt DB2-data fra en plattform til en annen. Windows-plattformer bruker for eksempel LOGICAL UNSHAPED-data, mens data på MVS og OS/390 vanligvis har formatet SHAPED VISUAL. Hvis de ikke har støtte for toveisattributter, blir ikke data som blir sendt fra DB2 for MVS eller OS/390 til DB2 Connect med Windows, vist på riktig måte.
Når data blir utvekslet mellom DB2 Connect og en database på en tjener, er det vanligvis mottakeren som konverterer de innkommende dataene. Dette gjelder vanligvis også transformering av toveisoppsett, som kommer i tillegg til den vanlige kodesettkonverteringen. Foreløpig er det imidlertid ingen DB2-vertsprodukter som har støtte for toveistransformering av CCSIDer eller toveisoppsett. Derfor har DB2 Connect blitt forbedret med en valgfri mulighet for å utføre toveistransformering av data det skal sende til, eller motta fra, tjenerdatabasen.
Hvis DB2 Connect skal utføre toveistransformering av utgående data til en tjenerdatabase, må den toveise CCSIDen til tjenerdatabasen overstyres (se (BIDI_NOTE2)). Dette gjør du ved å bruke BIDI-parameteren i PARMS-feltet i DCS-katalogposten for tjenerdatabasen.
Bruken av denne funksjonen kan best illustreres ved hjelp av et eksempel.
Tenk deg at en hebraisk DB2-klient kjører med CCSID 62213 (toveis strengtype 5), og at du ønsker tilgang til en DB2-vertsdatabase som kjører med CCSID 424 (toveis strengtype 4). Du vet imidlertid at dataene i DB2-vertsdatabasen i stedet er basert på CCSID 8616 (toveis strengtype 6).
Du har to problemer i denne situasjonen. Det første er at DB2-vertsdatabasen ikke kjenner til forskjellene mellom de toveise strengtypene med CCSIDene 424 og 8616. Det andre problemet er at DB2-vertsdatabasen ikke gjenkjenner CCSID 62213 til DB2-klienten. Den støtter bare CCSID 862, som er basert på det samme kodesettet som CCSID 62213.
Du må kontrollere at data som blir sendt til DB2-vertsdatabasen, har formatet toveis strengtype 6 til å begynne med, og at DB2 Connect vet at det må utføre toveistransformering av dataene det mottar fra DB2-vertsdatabasen. Bruk denne katalogiseringen for DB2-vertsdatabasen:
catalog dcs database nydb1 as TELAVIV parms ",,,,,,,,BIDI=8616"
Denne setningen ber DB2 Connect om å overstyre CCSID 424 til DB2-vertsdatabasen med CCSID 8616. Denne overstyringen består av disse prosessene:
Merknader:
Hvis en bestemt toveis CCSID skaper problemer som du ikke kan løse ved å følge disse anbefalingene, setter du systemvariabelen eller registerverdien DB2BIDI til NO.
Dette er eksempler på parameterstrenger du kan oppgi.
Du kan for eksempel oppgi denne strengen, der "\" (omvendt skråstrek) er skiftetegn for operativsystem:
I AIX:
NOMAP /u/bruker-ID/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\"\",,
Du kan også godta standardverdiene ved ikke å oppgi noen parameterstreng.
Merk: | Siden du må oppgi to par med doble anførselstegn når du oppgir
LOCALDATE-masken i parameterstrengen, må du bruke operativsystemskiftetegnet
"\" (omvendt skråstrek, for eksempel:
db2 catalog dcs db x as y parms \",,,,,,LOCALDATE=\"\"YYMMDD\"\"\"Da får du denne DCS-katalogposten: Post i DCS 1: Navn på lokal database = %1 Navn på måldatabase = %1 Navn på applikasjonsklient = DCS-parametere = ,,,,,,LOCALDATE="YYMMDD" Kommentar = Utgavenivå på DCS-katalogen = 0x0100 |
Du kan oppgi følgende opplysninger i systemets databasekatalog:
Format: 1-8 alfanumeriske enkeltbytetegn, inkludert nummertegnet (#), krøllalfa (@), dollartegnet ($) og understreking (_). Det kan ikke starte med en understreking eller et tall.
For hver database må du definere minst en post i hver enkelt av de tre katalogene (nodekatalogen, DCS-katalogen og systemets databasekatalog). I enkelte tilfeller bør du definere flere poster for databasen.
Det kan for eksempel hende at du vil slå av SQLCODE-konvertering for applikasjoner som ble konvertert fra verts- eller AS/400-databasetjeneren, men godta standardkonverteringen for applikasjoner som ble utviklet for klient/tjener-miljøet. Slik gjør du det:
Begge kallenavnene er knyttet til den samme databasen, et med SQLCODE-konvertering og et annet uten SQLCODE-konvertering.