DB2 Connect Brugervejledning

Indsamling af oplysninger

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å.

Nodekatalog

Du kan angive følgende oplysninger i nodekataloget:

Nodenavn
Et kaldenavn for den værts- eller AS/400-databaseserver, hvor den eksterne database er placeret. Navnet er brugerdefineret. Samme nodenavn skal skrives i tabellen Parametre til nodekatalog og i tabellen Parametre til systemdatabasekatalog.

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.

Protokol
Kan være APPC eller TCPIP.

Symbolsk destinationsnavn
Når du definerer en APPC-node, skal du bruge det symbolske destinationsnavn, der er angivet i CPI Communications Side Information Table, f.eks. navnet på CPI-C Symbolic Destination Properties, når Microsoft SNA Server benyttes. Værdien kan rekvireres fra den person, som installerede eller konfigurerede SNA. Der skelnes mellem store og små bogstaver i det symbolske destinationsnavn. Returkode SQL1338 kan blive vist, hvis der ikke er brugt den rigtige kombination af store og små bogstaver i navne.

Sikkerhedstype
Den type sikkerhedskontrol, der skal udføres. For APPC-noder er de gyldige værdier SAME og PROGRAM. For TCP/IP-noder kan SECURITY SOCKS defineres. Værdien angiver, at noden er SOCKS-aktiveret. I det tilfælde skal systemvariablerne SOCKS_NS og SOCKS_SERVER defineres, så SOCKS aktiveres. Der er flere oplysninger i Sikkerhed og i bogen Command Reference.

Eksternt TCP/IP-værtsnavn eller IP-adresse
Navnet eller adressen på den eksterne TCP/IP-vært, når der defineres en TCP/IP-node. Hvis der angives et værtsnavn, skal det opløses til en adresse på DB2 Connect-arbejdsstationen, enten vha. opslag på en navneserver eller en indgang i den lokale TCP/IP-værtsfil.

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.

TCP/IP-servicenavn eller -portnummer
Det eksterne TCP/IP-servicenavn eller -portnummer, når der defineres en TCP/IP-node. Det skal være defineret over for TCP/IP på den eksterne vært. Portnummer 446 er registreret som standardportnummer for DRDA.

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.

Katalog over databaseforbindelser (DCS)

Du kan angive følgende oplysninger i DCS-kataloget:

Databasenavn
Et brugerdefineret kaldenavn for værts- eller AS/400-databaseserveren. Samme databasenavn skal skrives i tabellen Parametre til DCS-katalog og i tabellen Parametre til Systemdatabasekatalog.

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.

Navn på måldatabase
Værts- eller AS/400-databaseserveren:

MVS/ESA
Et subsystem i DB2 Universal Database til OS/390, der identificeres vha. dets LOCATION NAME.

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.

OS/390
Et subsystem i DB2 Universal Database til OS/390, der identificeres vha. dets LOCATION NAME.

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.

VSE og VM
Databasenavnet (DBNAME)

OS/400
Relationsdatabasenavnet (RDBNAME)

Andre
På OS/2-, Windows NT-, Windows 2000- og UNIX-baserede systemer: Det databasealias, der findes i databasekataloget.

Navn på applikations-requester
Navnet på den applikations-requester, som sender SQL-forespørgsler til DRDA-applikationsservere. Applikations-requesteren håndterer forespørgsler på vegne af en applikation.

Format: AR <applikations-requesternavn>

Standardværdien er DB2 Connect-applikations-requesteren.

Parametre
Hvis du vil ændre standardværdierne, kan du angive en eller flere af følgende parametre i den angivne rækkefølge. Parametrene kan ikke angives vha. Klientkonfiguration, og parametre, der angives vha. DB2-kommandolinien, skal omsluttes af enkelte anførselstegn (f.eks. i OS/2 og Windows NT) eller af dobbelte anførselstegn (f.eks. i AIX):

omdefinitionsfil
Navnet på en fil, der erstatter standardfilen til omdefinition af SQLCODE. Angiv NOMAP, hvis du vil deaktivere omdefinition af SQLCODE-værdier. Der er flere oplysninger i Konvertering af SQLCODE-værdier.

,D
Den anden positionsparameter. Hvis den angives, vil applikationen afbryde forbindelsen til værts- eller AS/400-databaseserveren, når en af følgende SQLCODE-værdier returneres:
   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.

,,INTERRUPT_ENABLED
Den tredje positionsparameter. Hvis INTERRUPT_ENABLED er konfigureret i DCS-kataloget på DB2 Connect-arbejdsstationen, og en klientapplikation afsender et interrupt, mens den er forbundet med værts- eller AS/400-databaseserveren, vil DB2 Connect udføre dette interrupt ved at afbryde forbindelsen og udføre rollback af unit of work. Denne interrupt-behandling understøttes i AIX, OS/2, Windows NT og Windows 2000.

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.

,,,,,SYSPLEX
Den sjette positionsparameter kan benyttes til at aktivere SYSPLEX-støtte i DB2 Connect til en bestemt database.

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.

,,,,,,LOCALDATE="<værdi>"
Den syvende positionsparameter benyttes til at aktivere understøttelse i DB2 Connect af datoformatering. Det gøres ved at angive en datomaske som <værdi>.

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:

  1. Der må højst være én sekvens af Y'er, M'er og D'er, hvor Y er et ciffer i årstallet, M i måneden og D i dagen.
  2. Der må højst være 4 Y'er i sekvensen.
  3. Der må højst være 2 M'er i sekvensen.
  4. Der må højst være 2 D'er i sekvensen.

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:

  1. Der opstår ikke nogen SQL-fejl.
  2. Resultatet er en datoværdi i ISO-lignende (ISO og JIS) format.
  3. Dataområdet til resultatet er på mindst 10 byte. Det er den mindste størrelse på dataområdet, for at datoværdien kan gemmes, også selv om datoformatet ikke ændres. Det gælder også, selv om datoformatet ændres, så det er kortere end 10 byte.
  4. I DCS-katalogindgangen er angivet en gyldig maske for datoformatet, og der er plads til resultatet i dataområdet.

,,,,,,,CHGPWD_SDN=<navn>
Den ottende positionsparameter bruges til at angive det symbolske destinationsnavn, der skal anvendes til styring af udløb af kodeord (PEM). Der skelnes mellem store og små bogstaver i værdien for <navn>.

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=<ccsid>
Den niende positionsparameter benyttes til at angive den tovejs-CCSID (Bidirectional CCSID), der skal bruges til at tilsidesætte serverdatabasens standardværdi for tovejs-CCSID. For eksempel:
    ",,,,,,,,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:

  1. DB2 Connect opretter forbindelse til DB2-databasen på værtssystemet vha. CCSID 862.
  2. DB2 Connect konverterer layout for tovejssprogdata, som skal sendes til DB2-databasen på værtssystemet fra CCSID 62213, (tovejsstrengtype 5) til CCSID 62221 (tovejsstrengtype 6).
  3. DB2 Connect konverterer layout for tovejssprogdata, der modtages fra DB2-databasen på værtssystemet, fra CCSID 8616 (tovejsstrengtype 6) til CCSID 62213 (tovejsstrengtype 5).

Bemærkninger:

  1. Systemvariablen eller registerværdien DB2BIDI skal angives til YES, for at BIDI-parameteren kan få virkning.

  2. Hvis du ønsker, at DB2 Connect skal konvertere layout for data, der skal sendes til DB2-databasen på værtssystemet, skal du stadig tilføje BIDI-parameteren i feltet PARMS i DCS-databasekataloget, selvom du ikke behøver at erstatte CCSID'en. I dette tilfælde er den CCSID, du skal angive, standard-CCSID'en for DB2-databasen på værtssystemet.

  3. I visse tilfælde kan brug af tovejs-CCSID betyde ændring af selve SQL-forespørgslen, så den ikke bliver accepteret af DB2-serveren. Du skal især søge at undgå brug af CCSID'erne IMPLICIT CONTEXTUAL og IMPLICIT RIGHT-TO-LEFT, hvis der kan anvendes en anden streng. CONTEXTUAL CCSID'er kan give uventede resultater, hvis SQL-forespørgslen indeholder tegnstrenge omgivet af anførselstegn. Undgå brug af tegnstrenge omgivet af anførselstegn i SQL-sætninger. Brug værtsvariabler i stedet, når det kan lade sig gøre.

    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.

Angivelse af parameterstrengen

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

Systemdatabasekatalog

Du kan angive følgende oplysninger i systemdatabasekataloget:

Databasenavn
Samme værdi, som du skrev i tabellen Parametre til katalog over databaseforbindelser (DCS).

Databasealias
Et alias for værts- eller AS/400-databaseserveren. Navnet benyttes af applikationer, der skal have adgang til databasen. Standardværdien er den værdi, du angiver som Databasenavn.

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.

Nodenavn
Samme værdi, som du skrev i tabellen Parametre til nodekatalog.

Brugervalidering
Brugervalidering (Authentication) angiver, hvor brugerens navn og kodeord valideres. De gyldige værdier er: SERVER, SERVER_ENCRYPT, CLIENT, DCE, DCS og DCS_ENCRYPT. Der er flere oplysninger i Sikkerhed.

Definition af flere indgange for samme database

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.


[ Øverst på siden | Forrige side | Næste side | Indholdsfortegnelse | Stikordsregister ]