Brukerhåndbok

Samle inn opplysninger

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.

Nodekatalog

Du kan oppgi følgende opplysninger i nodekatalogen:

Nodenavn
Et kallenavn på verts- eller AS/400-databasetjeneren som fjerndatabasen ligger på. Dette navnet er brukerdefinert. Skriv det samme nodenavnet i både tabellen for nodekatalogparametere og i parametertabellen for systemets databasekatalog.

Format: 1-8 alfanumeriske enkeltbytetegn, inkludert nummertegnet (#), krøllalfa (@), dollartegnet ($) og understreking (_). Det kan ikke starte med en understreking eller et tall.

Protokoll
Kan være APPC eller TCPIP.

Navn på symbolsk mottaker
Når du definerer en APPC-node, bruker du navnet på den symbolske mottakeren som ble oppgitt i CPI-C-tilleggsinformasjonstabellen (for eksempel navnet i egenskapene for symbolsk mottaker for CPI-C når du bruker Microsoft SNA Server). Du kan få denne verdien fra personen som installerte og/eller konfigurerte SNA. Navnet på den symbolske mottakeren skiller mellom store og små bokstaver (du kan få returkoden SQL1338 hvis det ikke er samsvar mellom navn med store og små bokstaver).

Sikkerhetstype
Typen sikkerhetskontroll som blir utført. For APPC-noder er de gyldige alternativene SAME, PROGRAM og NONE. For TCP/IP-noder er SECURITY SOCKS et alternativ som oppgir at noden blir SOCKS-aktivert. I dette tilfellet er systemvariablene SOCKS_NS og SOCKS_SERVER obligatoriske, og de må være definert for å aktivere SOCKS. Du finner flere opplysninger om dette i Sikkerhet og i Command Reference.

TCP/IP-navn eller IP-adresse for fjernvert
Når du definerer en TCP/IP-node, må du enten oppgi TCP/IP-navnet eller TCP/IP-adressen for fjernverten. Hvis du oppgir et vertsnavn, må det konverteres på DB2 Connect-arbeidsstasjonen, enten ved hjelp av oppslag på navnetjeneren i kontrollområdet (DNS) eller ved hjelp av en post i den lokale TCP/IP-vertsfilen.

For DB2 for OS/390-fjernverter vises vertsnavnet i DSNL004I-meldingen (DOMAIN=vertsnavn) når DDF (Distributed Data Facility) blir startet.

TCP/IP-tjenestenavn eller -portnummer
Når du definerer en TCP/IP-node, må du enten oppgi TCP/IP-tjenestenavnet eller portnummeret for fjernverten. Dette må defineres for TCP/IP på fjernverten. Portnummeret 446 er registrert som standard portnummer for DRDA.

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.

DCS-katalog

Du kan oppgi følgende opplysninger i DCS-katalogen:

Databasenavn
Et brukerdefinert kallenavn på verts- eller AS/400-databasetjeneren. Bruk det samme databasenavnet i både tabellen for DCS-katalogparametere og i parametertabellen for systemets databasekatalog.

Format: 1-8 alfanumeriske enkeltbytetegn, inkludert nummertegnet (#), krøllalfa (@), dollartegnet ($) og understreking (_). Det kan ikke starte med en understreking eller et tall.

Navn på måldatabase
Databasen på verts- eller AS/400-databasetjeneren:

MVS/ESA
Et delsystem for DB2 Universal Database for OS/390 som blir identifisert ved hjelp av delsystemets LOCATION NAME.

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.

OS/390
Et DB2 Universal Database for OS/390-delsystem som blir identifisert ved hjelp av delsystemets LOCATION NAME.

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.

VSE eller VM
Databasenavnet (DBNAME)

OS/400
Navnet på relasjonsdatabasen (RDBNAME)

Andre
For systemer med OS/2, Windows NT, Windows 2000 og UNIX brukes databasekallenavnet som ble funnet i databasekatalogen.

Navn på applikasjonsklient
Navnet på applikasjonsklienten som videreformidler SQL-forespørsler til DRDA-applikasjonstjenere. Denne applikasjonsklienten behandler forespørsler på vegne av et applikasjonsprogram.

Format: AR <applikasjonsklientnavn>

Standardverdien er DB2 Connect-applikasjonsklienten.

Parameterstreng
Hvis du vil endre standardverdiene, oppgir du en av eller alle parameterne nedenfor i den gitte rekkefølgen. Du kan ikke definere parameterstrengen ved hjelp av Klientkonfigureringsassistent, og når du bruker CLP, må parameterstrengen stå i enkle anførselstegn (for eksempel på OS/2 eller Windows NT), eller i doble anførselstegn (for eksempel på AIX):

map-fil
Navnet på en SQLCODE-konverteringsfil som overstyrer SQLCODE-konverteringen som er standard. Hvis du vil slå av SQLCODE-konvertering, oppgir du NOMAP. Du finner flere opplysninger i SQLCODE-konvertering.

,D
Dette er den andre posisjonsavhengige parameteren. Hvis den blir oppgitt, blir applikasjonen frakoblet databasen på verts- eller AS/400-databasetjeneren når en av disse SQLCODE-verdiene blir returnert:

   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.

,,INTERRUPT_ENABLED
Dette er den tredje posisjonsavhengige parameteren. Hvis INTERRUPT_ENABLED er konfigurert i DCS-katalogen på DB2 Connect-arbeidsstasjonen og en klientapplikasjon sender en avbruddsforespørsel mens den er tilkoblet verts- eller AS/400-databasetjeneren, utfører DB2 Connect avbruddet ved å avbryte tilkoblingen og tilbakestille arbeidsenheten. Denne typen avbrudd er støttet på AIX, OS/2, Windows NT og Windows 2000.

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.

,,,,,SYSPLEX
Denne parameteren, som er den sjette posisjonsavhengige parameteren, kan brukes til å eksplisitt aktivere DB2 Connect SYSPLEX-støtte for en bestemt database.

Det er også introdusert en ny profilvariabel (system eller register) kalt DB2SYSPLEX_SERVER, som kan brukes til å deaktivere SYSPLEX-støtten på arbeidsstasjonsnivå.

,,,,,,LOCALDATE="<verdi>"
Denne parameteren, som er den sjuende posisjonsavhengige parameteren, blir brukt til å aktivere datoformateringsstøtten for DB2 Connect. Dette blir implementert ved hjelp av en datomaske for <verdien>:

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:

  1. Det kan maksimalt være en sekvens med Y-er, M-er og D-er, der Y er årstallet, M er måneden og D er dagen.
  2. Største antall Y-er i en sekvens, er 4.
  3. Største antall M-er i en sekvens, er 2.
  4. Største antall D-er i en sekvens, er 2.

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:

  1. Det er ingen SQL-feil.
  2. Utdataene er en datoverdi i et ISO-liknende (ISO og JIS) format.
  3. Utdataområdet er minst på 10 byte. Dette er minste størrelse på et utdataområde for at en dataverdi skal kunne lagres der, selv om INGEN datoformattransformeringer skal utføres. Dette kravet gjelder selv om datoformatmasken ender opp som kortere enn 10 byte.
  4. Det er spesifisert en gyldig datoformatmaske i DCS-katalogposten, og denne masken passer i utdataområdet.

,,,,,,,CHGPWD_SDN=<navn>
Denne parameteren, som er den åttende posisjonsavhengige parameteren, brukes til å oppgi navnet på den symbolske mottakeren som skal brukes for PEM (Password Expiration Management). Verdien som er oppgitt for <navn> skiller mellom store og små bokstaver.

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=<ccsid>
Denne parameteren, som er den niende posisjonsavhengige parameteren, blir brukt til å oppgi den toveise (BiDi) CCSIDen som skal brukes til å overstyre den toveise CCSIDen som er standardverdi for tjenerdatabasen. For eksempel:
    ",,,,,,,,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:

  1. DB2 Connect kobler seg til DB2-vertsdatabasen med CCSID 862.
  2. DB2 Connect utfører toveistransformering av data det skal sende til DB2-vertsdatabasen, fra CCSID 62213 (toveis strengtype 5) til CCSID 62221 (toveis strengtype 6).
  3. DB2 Connect utfører toveistransformering av data det mottar fra DB2-vertsdatabasen, fra CCSID 8616 (toveis strengtype 6) til CCSID 62213 (toveis strengtype 5).

Merknader:

  1. Systemvariabelen eller registerverdien DB2BIDI må settes til YES for å aktivere toveisparameteren.

  2. Hvis du vil at DB2 Connect skal utføre oppsettransformering av dataene det skal sende til DB2-vertsdatabasen, selv om du ikke må overstyre CCSIDen, må du likevel tilføye toveisparameteren i PARMS-feltet for DCS-databasekatalogen. I dette tilfellet oppgir du CCSIDen som er standardverdi for DB2-vertsdatabasen.

  3. I noen tilfeller kan bruk av en toveis CCSID føre til at selve SQL-spørringen blir endret, slik at DB2-tjeneren ikke gjenkjenner den. Du bør for eksempel prøve å unngå å bruke CCSIDer av typen IMPLICIT CONTEXTUAL og IMPLICIT RIGHT-TO-LEFT når en annen strengtype kan brukes. CCSIDer av typen CONTEXTUAL kan gi uforutsette resultater hvis SQL-spørringen inneholder strenger i doble anførselstegn. Unngå å bruke strenger i doble anførselstegn i SQL-setninger og bruk vertsvariabler i stedet når det er mulig.

    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.

Oppgi parameterstrengen

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

Systemets databasekatalog

Du kan oppgi følgende opplysninger i systemets databasekatalog:

Databasenavn
Den samme verdien som du oppgav i tabellen for DCS-katalogparametere.

Databasekallenavn
Et kallenavn for verts- eller AS/400-databasetjeneren. Dette navnet blir brukt av alle applikasjonsprogrammer som går inn i databasen. Standardverdien er verdien du oppgir for databasenavn.

Format: 1-8 alfanumeriske enkeltbytetegn, inkludert nummertegnet (#), krøllalfa (@), dollartegnet ($) og understreking (_). Det kan ikke starte med en understreking eller et tall.

Nodenavn
Den samme verdien som du oppgav i tabellen for nodekatalogparametere.

Autentisering
Oppgir hvor valideringen av bruker-IDen og passordet blir utført. Du kan velge mellom disse alternativene: SERVER, SERVER_ENCRYPT, CLIENT, DCE, DCS og DCS_ENCRYPT. Du finner flere opplysninger i Sikkerhet.

Definere flere poster for den samme databasen

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.


[ Øverst på siden | Forrige side | Neste side | Innholdsfortegnelse | Stikkordregister ]