Endringsmerker angir tekst som er tilføyd eller endret. En loddrett strek ( | ) angir informasjon som er blitt tilføyd eller endret for versjon 8.2 opprettingspakke 4 (tilsvarer versjon 8.1 opprettingspakke 11).
Det kan være situasjoner der du må installere et DB2-produkt som har et annet nivå enn versjonen av et annet DB2-produkt som allerede er installert på maskinen. DB2-produkter må være på samme nivå.
Hvis du skal installere et produkt som har et høyere nivå enn andre DB2-produkter på maskinen, må du oppdatere de eksisterende DB2-produktene til det høyere nivået. Hvis du for eksempel installerer DB2 Connect for iSeries på nivået for opprettingspakke 10 og dine andre DB2-produkter har opprettingspakke 9, må du installere opprettingspakke 10 for de installerte DB2-produktene før du installerer DB2 Connect for iSeries med opprettingspakke 10.
Hvis du skal installere et produkt på en maskin som har en nyere versjon av et DB2-produkt installert, må du også følge noen retningslinjer:
db2licm -a filnavnder filnavn er navnet på
lisensfilen, som du finner på originalmediet i katalogen db2\license. Du kan også legge inn denne lisensen
i katalogen db2\license for opprettingspakken, så vil
lisensen bli installert av installeringsprogrammet.
Før du installerer et ekstra produkt eller en ekstra komponent, må du stoppe følgende:
Forekomstene og DAS som må stoppes, er de som tilhører DB2-installasjonen der det ekstra DB2-produktet eller den ekstra DB2-komponenten skal installeres.
Du finner mer informasjon i Readme-filen for opprettingspakken.
Hvis DB2 DAS ikke finnes på det aktuelle systemet, og det ekstra produktet eller komponenten krever eller støtter DB2 DAS, må db2setup konfigurere DB2 DAS under installeringen. På noen plattformer kan det oppstå feil når DB2 DAS blir opprettet med db2setup. Disse feilene er forventet og kan overses.
Du finner db2setup-programmet på produkt-CDen eller -bildet med DB2 for det ekstra produktet eller komponenten du installerer.
Slå opp i bøkene Command Reference og Installation and Configuration Supplement hvis du vil vite mer om hvordan du bruker db2setup.
Du finner db2_install-skriptet på produkt-CDen eller -bildet med DB2 for det ekstra produktet eller komponenten du installerer.
Slå opp i boken Installation and Configuration Supplement hvis du vil vite mer om hvordan du bruker db2_install-skriptet.
Slå opp i boken Installation and Configuration Supplement hvis du vil vite mer om hvordan du bruker systeminstalleringsprogrammet.
For eksempel:
Etter installeringen må du da installere den vanlige opprettingspakke 10.
Pakken db2cliv81 er allerede installert på systemet. Installering av rettelsen nnnnnnn-nnn ble avbrutt. Hvis du vil installere denne rettelsen på nytt, må du deinstallere den før du prøver å installere den på nytt.Denne feilen oppstår fordi db2cliv81 i systemet allerede er på det samme nivået som opprettingspakken som blir installert. Du kan overse slike feil. Bruk systeminstalleringsprogrammet til å bekrefte at DB2-komponenten eller -pakken faktisk er på samme nivå som opprettingspakken som blir installert.
Hvis du oppretter en database med DB2 Universal Database versjon 8.2, kan du ikke bruke den databasen med et versjon 8.1-produkt. Den databasen kan bare brukes med versjon 8.2 eller høyere.
Databaser som er opprettet med DB2 UDB versjon 8.2-nivå, kan ha funksjonalitet som ikke var tilgjengelig i tidligere versjoner. Denne forskjellen kan føre til uventede og uønskede resultater hvis du prøver å flytte den nye databasen til en tidligere utgave av DB2 UDB.
Avsnittet "DB2 client overview" i boken DB2 Quick |Beginnings for Clients inneholder denne setningen:
DB2 clients can |connect to DB2 servers two releases later or one release earlier than the |client's release level, as well as to servers at the same release level.|
Denne setningen skal erstattes av dette:
|While connections from Version N clients to Version N + 2 servers are |possible in some environments, the DB2 support team will only provide support |for this configuration as long as Version N is still in service. Once Version |N is withdrawn from service, this configuration is no longer supported by |the DB2 support team. DB2 Version 7 clients connecting to a DB2 Version 8 |server is no longer supported by the DB2 support team because Version 7 has |been withdrawn from service.
Registerendringer som er gjort i DB2 UDB versjon 8.2, går tapt når du migrerer tilbake til DB2 UDB versjon 8.1. Registeret går tilbake til filen HealthRules.reg i versjon 8.1, som inneholder innstillingene som gjaldt før du oppgraderte til DB2 UDB versjon 8.2 og begynte å bruke innstillingene i filen HealthRules2.reg.
Før DB2 Universal Database (UDB) versjon 8, fungerte opprettingspakker bare som oppdateringer til installerte DB2 UDB-pakker eller filsett på ett bestemt sted. Det betydde at installeringen av opprettingspakker erstattet eksisterende filer med oppdaterte filer fra opprettingspakkene. Det var ikke mulig å ha flere DB2-opprettingspakkenivåer på ett og samme system. Nå kan DB2 UDB Enterprise Server Edition (ESE) finnes på flere opprettingspakkenivåer på samme system for Linux-baserte og UNIX-baserte operativsystemer. Denne funksjonen, som har vært støttet i produksjonsoperativsystemene siden versjon 8.1.2, oppnås ved bruk av følgende to typer opprettingspakker:
Du kan oppdatere en flerforekomstversjon av en opprettingspakke til et annet nivå på en av disse måtene:
Du finner mer informasjon om alternative opprettingspakker her:
Fra og med versjon 8.2.2 (tilsvarer versjon 8.1 opprettingspakke 9) kan innholdet i Query Patroller-styringstabellen TRACK_QUERY_INFO som ble lagret i et 32-bits miljø, brukes i et 64-bits miljø. Denne funksjonen gjør det enklere å migrere til et 64-bits miljø. Informasjon som blir lagret i Query Patroller-styringstabellen TRACK_QUERY_INFO med versjon 8.2.2, kan ikke brukes til å generere historiske data for den spørringen eller til å utføre holdte spørringer under noe tidligere opprettingspakkenivå.
Disse begrensningene gjelder for støtten for DB2 Universal Database (UDB) Enterprise Server Edition versjon 8 Datavarehussenter på tidligere tjenere:
Når du bruker utviklingssenteret eller en applikasjonsutviklingsklient for DB2 Universal Database (UDB) versjon 8 på Windows eller UNIX, må disse APARene installeres på tjeneren for å aktivere støtte for SQLJ og SQL Assist:
Du kan starte både versjon 7 og versjon 8 av SQL Assist fra DB2 Universal Database versjon 8. Du kan starte versjon 7 fra DB2 Datavarehussenter. Alle andre sentre starter den nyeste versjon 8. Produkthjelpen har ekstra informasjon om SQL Assist, versjon 7.
I versjon 7 overså Unicode-tjenere alle grafiske kodesett som ble sendt fra applikasjoner på tilkoblingstidspunktet og antok at UCS2 Unicode (kodesett 1200) ble brukt. Unicode-tjenere med versjon 8 respekterer nå kodesettet sendt av klienten.
DB2 UDB versjon 8.2 bruker en ny fil for databasesystemets konfigurasjonsparametere på 16K, kalt SQLDBCONF. Dette er en annen fil enn den tilsvarende filen k DB2 UDB versjon 8.1 på 4K, som ble kalt SQLDBCON.
Etter migreringen til DB2 UDB versjon 8.2 migrerer produktet innholdet i 4K-filen fra versjon 8.1 og bruker filen på 16K til logging av endringer i databasesystemets konfigurasjonsparametere. Versjon 8.1-filen blir beholdt, men ikke brukt.
Hvis du migrerer tilbake til DB2 UDB versjon 8.1, ta DB2 UDB versjon 8.1-produktet i bruk den opprinnelige 4K-filen fra versjon 8.1 igjen for logging av endringer i databasesystemets konfigurasjonsparametere. 16K-filen fra versjon 8.2 blir beholdt, men blir ikke gjenkjent av DB2 UDB versjon 8.1-produktet. Endringer som er gjort i 16K-filen mellom migreringen til versjon 8.2 og migreringen tilbake til versjon 8.1 blir i praksis skjult for det tidligere DB2 UDB-nivået fordi endringene ikke blir migrert til den opprinnelige 4K-filen.
I tillegg er det slik at hvis du migrerer til DB2 UDB versjon 8.2 igjen, vil DB2 UDB versjon 8.2-produktet oppdage at 16K-filen allerede finnes, og vil derfor ta i bruk 16K-filen fra versjon 8.2 for logging av endringer i databasesystemets konfigurasjonsparametere. 4K-filen fra versjon 8.1 blir beholdt, men blir ikke gjenkjent av DB2 UDB versjon 8.2-produktet. Endringer som er gjort i 4K-filen mellom migreringen tilbake til versjon 8.2 og remigreringen til versjon 8.2 blir i praksis skjult for det nyere DB2 UDB-nivået fordi endringene ikke blir migrert til den eksisterende 16K-filen.
Formatet til filen db2diag.log er forbedret på flere måter i versjon 8.2. Det er nå enklere å lese loggfilen manuelt, og å analysere den med programvare. Forbedringene omfatter:
I tillegg er det gjort andre endringer, for eksempel er databasefeltnavnet endret til DB.
Aktivitetsposter er tilføyd som feilsøkingsmeldinger i filen db2diag.log. Eksempler på slike aktiviteter:
Aktivitetsposter har "Aktivitet/Event" spesifisert i feltet LEVEL. Selv om aktiviteter ikke er feil, kan de blir logget ved andre feilsøkingsnivåer enn 4 (Informasjon) eller 3 (Advarsel), avhengig av betydningen.
Fra og med versjon 8.2 blir disse oppdateringene loggført i filen db2diag.log:
Meldingene for disse oppdateringene blir loggført med høye feilsøkingsnivåer på grunn av sin betydning.
Disse typene db2set-profilregisteroppdateringer logges:
2004-04-22-19.19.14.156959-240 I79582C286 LEVEL: Event PID : 2437242 TID : 1 PROC : db2set INSTANCE: db2user NODE : 000 FUNCTION: DB2 UDB, oper system services, db2set_main, probe:40 CHANGE : CFG DB2SET: DB2DBDFT: From: "OLDDB" To: "SAMPLE"
CHANGE : CFG DB2SET: DB2DBDFT: From: "SAMPLE" To: ""
CHANGE : CFG DB2SET: Profile registry was reset
Eksempler for DB- og DBM-konfigurasjonsparameteroppdateringer:
CHANGE : CFG DB SAMPLE: "Maxlocks" From: "10" To: "20" CHANGE : CFG DBM: "Diaglevel" From: "3" To: "1" CHANGE : CFG DBM: Reset to the system defaults
Du finner disse konfigurasjonsoppdateringsmeldingene ved å bruke verktøyet db2diag. For eksempel:
DB2 Universal Database(TM) (UDB) for Linux, UNIX og Windows(R), versjon 8.2.2 (tilsvarer versjon 8.1 opprettingspakke 9) støtter JDK 1.4.2 på alle DB2 UDB-støttede 32-bits og 64-bits operativsystemer på arbeidsstasjoner. Denne støtten omfatter, men er ikke begrenset til, støtte for å bygge og kjøre Java-klientapplikasjoner, bygge og kjøre Java-rutiner fra kommandolinjen, bygge og kjøre Java-rutiner fra DB2 Utviklingssenter der dette er støttet, samt å kjøre andre DB2-verktøy.
Hvis du installerer DB2 UDB versjon 8.2, blir den nyeste støttede versjonen av Java-utviklersettet også installert hvis det ikke allerede er installert, med mindre DB2 UDB-installeringen er en oppdatering av en tidligere DB2 UDB versjon 8-installasjon. Hvis du oppdaterer en tidligere installasjon av DB2 UDB versjon 8, må du installere Java-utviklersettet fra CDen.
Tabellen nedenfor viser de DB2-støttede 32-bits og 64-bits operativsystemmiljøene for arbeidsstasjoner og det nyeste støttede JDK-nivået for hvert enkelt miljø. Hvis du vil vite mer om tidligere JDK-støtte, kan du gå til nettstedet for Java Application Development på http://www.ibm.com/software/data/db2/udb/ad/v8/java/.
| DB2-støttet miljø | Siste støttede JDK-nivå |
|---|---|
| Windows IA/AMD 32-bits | JDK 1.4.2 |
| Windows IA 64-bits | JDK 1.4.2 |
| Windows AMD/EM64T 64-bits | JDK 1.4.2 |
| AIX(R) 4.3.3 32-bits | JDK 1.3.1 SR6 [2] |
| AIX 5 (hybrid [1]) | JDK 1.4.2 |
| Solaris (hybrid [1]) | JDK 1.4.2 |
| HPUX RISC & Itanium (hybrid [1]) | JDK 1.4.2.01 |
| Linux AMD/EM64T 32-bits, 64-bits (hybrid [1]) | JDK 1.4.2 [3] |
| Linux IA 32-bits | JDK 1.4.2 |
| Linux IA 64-bits | JDK 1.4.2 |
| Linux 390 31-bits | JDK 1.4.2 |
| Linux 390 64-bits | JDK 1.4.2 |
| Linux PPC (hybrid [1]) | JDK 1.4.2 |
En oppdatert prosedyre for konfigurering av Java-miljøet i Linux er vist nedenfor.
Slik bygger du Java-applikasjoner på Linux med DB2 JDBC-støtte:
Hvis du skal kjøre lagrede Java-prosedyrer eller brukerdefinerte funksjoner, må Linux Runtime Linker ha tilgang til bestemte delte Java-biblioteker, og DB2 UDB må kunne laste inn både disse bibliotekene og Java Virtual Machine. Prosessen som kjører lagrede prosedyrer og brukerdefinerte funksjoner, laster inn biblioteker bare på sikre steder, slik det er definert i filen /etc/ld.so.conf. Ett av disse sikre stedene er /usr/lib. Resten av instruksjonene viser hvilke biblioteker som krever symbolske linker i /usr/lib.
cd /usr/lib ln -fs JAVAHOME/jre/bin/libjava.so . ln -fs JAVAHOME/jre/bin/classic/libjvm.so . ln -fs JAVAHOME/jre/bin/libhpi.so .der JAVAHOME er basiskatalogen for IBM Developer Kit. Hvis DB2 UDB ikke finner disse bibliotekene, får du en -4301-feil når du prøver å kjøre en Java-rutine, og det vil bli lagt inn meldinger i administrasjonsvarslingsloggen om bibliotekene som ikke ble funnet.
cd /usr/lib ln -fs JAVAHOME/jre/bin/libjava.so ln -fs JAVAHOME/jre/bin/classic/libjvm.so ln -fs JAVAHOME/jre/bin/libhpi.so ln -fs JAVAHOME/jre/bin/libjsig.soder JAVAHOME er basiskatalogen for IBM Developer Kit. Hvis DB2 UDB ikke finner disse bibliotekene, får du en -4301-feil når du prøver å kjøre en Java-rutine, og det vil bli lagt inn meldinger i administrasjonsvarslingsloggen om bibliotekene som ikke ble funnet.
cd /usr/lib ln -fs JAVAHOME/jre/bin/libjava.so ln -fs JAVAHOME/jre/bin/classic/libjvm.so ln -fs JAVAHOME/jre/bin/libhpi.so ln -fs JAVAHOME/jre/bin/libjsig.so ln -fs JAVAHOME/jre/bin/libjitc.so ln -fs JAVAHOME/jre/bin/libxhpi.so ln -fs JAVAHOME/jre/bin/libdbgmalloc.soder JAVAHOME er basiskatalogen for IBM Developer Kit. Hvis DB2 UDB ikke finner disse bibliotekene, får du en -4301-feil når du prøver å kjøre en Java-rutine, og det vil bli lagt inn meldinger i administrasjonsvarslingsloggen om bibliotekene som ikke ble funnet.
JAVAHOME/jre/binder JAVAHOME er basiskatalogen for IBM Developer Kit. Hvis DB2 UDB ikke finner disse bibliotekene, får du en -4301- eller or -1042-feil når du prøver å kjøre en Java-rutine.
I stedet for å oppretter linker eksplisitt til de delte bibliotekene i katalogen /usr/lib, kan du legge inn navnene på katalogene der de delte Java-bibliotekene lagres, i filen /etc/ld.so.conf. Denne filen krever root-tillatelse. Når du har oppdatert /etc/ld.so.conf, må du kjøre ldconfig-kommandoen som root for å aktivere endringene. Hvis det oppstår problemer med denne alternative prosedyren, oppretter du linkene i katalogen /usr/lib slik det er beskrevet ovenfor.
Hvis du bruker det 64-bits Microsoft XP-operativsystemet (2600) konfigurert til å bruke NETBIOS-protokollen med DB2-produktene, må du anskaffe en hurtigrettelse fra Microsoft. Kontakt Microsoft med Q-artikkelnummeret Q317437.
Operativsystemet Windows XP Home Edition støttes bare av DB2 Universal Database (UDB) Personal Edition-produkter.
Operativsystemet Windows XP Professional støttes av disse DB2-produktene:
Følgende DB2-produkter støttes på Windows XP bare til utviklings- eller testformål (produksjonsmiljøer krever Windows 2000 eller Windows Server 2003):
I DB2 Universal Database (UDB) versjon 8.2 kunne ikke kunder med DB2 UDB Workgroup Server Edition og DB2 UDB Express Edition (med en lisens med brukerbasert prismodell) installere DB2 UDB High Availability Disaster Recovery (HADR) som en funksjon med egen pris. Dette problemet er løst i DB2 UDB versjon 8.2 opprettingspakke 1 (tilsvarer versjon 8.1 opprettingspakke 8).
OLAP-funksjonene i DB2 Warehouse Manager Standard Edition versjon 8.2 er ikke kompatible med IBM DB2 OLAP Server FP3 (Essbase API nivå 6.5.4) og senere. Du bør bruke DB2 OLAP Server FP2 (Essbase 6.5.3) eller tidligere til dette problemet blir løst.
For å kunne bruke logger med Raw I/O-enheter før DB2 Universal Database (UDB) versjon 8.2.2 (tilsvarer versjon 8.1 opprettingspakke 9), måtte man binde en fysisk enhet til Linux-driveren for Raw Character-enhet med raw-funksjonen. Fra og med DB2 UDB versjon 8.2.2 (tilsvarer versjon 8.1 opprettingspakke 9), på 2.6 Linux-kjernen, kan Raw I/O for logger spesifiseres direkte. Hvis du for eksempel vil bruke enhetspartisjonen /dev/sdb1 for Raw-logger for SAMPLE-databasen, utfører du denne kommandoen:
db2 update db cfg for sample using newlogpath /dev/sdb1
Selv om DB2 UDB fremdeles støtter metoden med å bruke raw-funksjonen for ubehandlet (raw) I/U, frarådes det å bruke den i nyere distribusjoner, og den kan bli fjernet i fremtiden. Den anbefalte metoden er den nye metoden, der enhetene oppgis direkte.
DB2 Universal Database versjon 8.2 støtter Red Hat Enterprise Linux AS versjon 3 og 2.1. Datavarehussenteret støtter imidlertid bare Red Hat Enterprise Linux AS versjon 2.1. Datavarehussenteret bruker DataDirect ODBC-styreprogrammer som ikke støtter Red Hat Enterprise Linux AS versjon 3.1. Derfor støtter ikke datavarehussenteret ODBC-varehuskilder og varehusmål fra et Red Hat Enterprise Linux AS versjon 3.1-agentsted.
Når du kjører applikasjoner i et IBM WebSphere MQ-miljø (tidligere kalt IBM MQSeries), kan WebSphere MQ fungere som en XA-kompatibel transaksjonsstyrer som koordinerer eventuelle distribuerte tofaseiverksettingstransaksjoner. Når WebSphere MQ fungerer som en transaksjonsstyrer på denne måten og datakildene er fra et produkt i DB2-familien, er det flere konfigurasjonskrav. De fleste av disse kravene er allerede dokumentert. Du må for eksempel sette DB2-konfigurasjonsparameteren TP_MON_NAME til "MQ" i DB2 Runtime-klienten.
Det er imidlertid ett konfigurasjonskrav som ikke er blitt dokumentert. Kravet gjelder for DB2 Connect ved tilkobling til datakilder som er DB2 for OS/390-tjenere: Når du bruker WebSphere MQ til å koordinere distribuerte transaksjoner som omfatter DB2 for z/OS- og DB2 for iSeries-tjenere, må funksjonen for DB2 Connect-tilkoblingskonsentratoren aktiveres på portneren. Tilkoblingskonsentratoren er aktivert når verdien for konfigurasjonsparameteren MAX_CONNECTIONS er større enn verdien for MAX_COORDAGENTS. Hvis du ikke aktiverer tilkoblingskonsentratoren, kan du få uventede resultater for transaksjonene.
Microsofts japanske Windows Shift-JIS kodesett er registrert som IBMs CCSID (Coded Character Set Identifier) 943. Shift-JIS kodesettet på HP-UX-plattformen er imidlertid registrert som CCSID 5039. CCSID 5039 inneholder bare tegn i Japanese Industry Standard (JIS), og har ingen leverandørdefinerte tegn. Du kan bruke en DB2 Universal Database-database (UDB-database) med CCSID 5039 på HP-UX til å lagre Shift-JIS-tegn, men det vil bli utført kodesettkonvertering mellom CCSID 5039 og CCSID 943. Når du bruker Microsoft ODBC-applikasjoner, kan det oppstå et problem ved konvertering av data i CCSID 5039 til Unicode, på grunn av forskjeller mellom IBMs tabell for kodesettkonvertering og Microsofts tabell for kodesettkonvertering.
Listen nedenfor viser tegnene, ved konvertering fra CCSID 5039 til Unicode, som vil resultere i forskjellige kodeverdi avhengig av hvilken konverteringstabell som blir brukt (IBM eller Microsoft). For disse tegnene følger IBMs konverteringstabell JIS (Japanese Industry Standard) JISX0208 og JISX0221.
| Shift-JIS-kodeverdi (tegnnavn) | IBMs primære kodeverdi (Unicode-navn) | Microsofts primære kodeverdi (Unicode-navn) |
|---|---|---|
| X'815C' (gefirt-tankestrek) | U+2014 (gefirt-tankestrek) | U+2015 (vannrett stolpe) |
| X'8160' (bølgestrek) | U+301C (bølgestrek) | U+FF5E (tilde med full bredde) |
| X'8161' (dobbelt vertikal linje) | U+2016 (dobbelt vertikal linje) | U+2225 (Parallell til) |
| X'817C' (minustegn) | U+2212 (minustegn) | U+FF0D (bindestrek med full bredde) |
For eksempel blir tegnet gefirt-tankestrek med CCSID 5039-kodeverdien X'815C' konvertert til Unicode-kodeverdien U+2014 ved bruk av IBMs konverteringstabell, men til U+2015 ved bruk av Microsofts konverteringstabell. Dette kan skape problemer for Microsoft ODBC-applikasjoner fordi de ville behandle U+2014 som en ugyldig kodeverdi. For å unngå disse potensielle problemene har DB2 UDB Microsofts alternative konverteringstabell fra CCSID 5039 til Unicode, i tillegg til IBMs standard konverteringstabell. Du må erstatte IBMs standard konverteringstabell med den alternative konverteringstabellen fra Microsoft. Legg merke til at IBMs standard konverteringstabell fra Unicode til CCSID 5039 er identisk med Microsofts versjon.
Når du konverterer fra CCSID 5039 til Unicode, brukes DB2 Universal Databases standard tabell for kodesettkonvertering. Hvis du vil bruke en annen versjon av konverteringstabellen, for eksempel Microsoft-versjonen, må du manuelt erstatte filen med standard konverteringstabell (.cnv).
Før du erstatter den eksisterende tabellfilen for kodesettkonvertering i katalogen sqllib/conv, må du reservekopiere filen i tilfelle du ønsker å bytte tilbake til den. På UNIX og Linux er katalogen sqllib/conv knyttet til installeringsbanen for DB2 UDB.
For at erstatning av konverteringstabell skal fungere, må alle DB2 UDB-klienter som knyttes til den samme databasen, endre konverteringstabell. Ellers kan de ulike klientene lagre det samme tegnet med forskjellige kodeverdier.
Slik erstatter du DB2 UDBs standard konverteringstabell for konvertering fra CCSID 5039 til Unicode:
IBMs CCSID (Coded Character Set Identifier) for det japanske EUC-kodesettet er registrert som CCSID 954. CCSID 954 er en felles koding for japanske UNIX- og Linux-plattformer. Når du bruker Microsoft ODBC-applikasjoner til å knytte deg til en DB2 Universal Database-database med CCSID 954, kan det oppstå et problem ved konvertering av data fra CCSID 954 til Unicode. Dette potensielle problemet skyldes forskjeller mellom IBMs tabell for kodesettkonvertering og Microsofts tabell for kodesettkonvertering. IBMs konverteringstabell samsvarer med tegnnavnene slik de er spesifisert i JIS (Japanese Industry Standard) JISX0208, JISX0212 og JISX0221.
Listen nedenfor viser tegnene, ved konvertering fra CCSID 954 til Unicode, som vil resultere i forskjellige kodeverdi avhengig av hvilken konverteringstabell som blir brukt (IBM eller Microsoft).
| EUC-JP-kodeverdi (tegnnavn) | IBMs primære kodeverdi (Unicode-navn) | Microsofts primære kodeverdi (Unicode-navn) |
|---|---|---|
| X'A1BD' (gefirt-tankestrek) | U+2014 (gefirt-tankestrek) | U+2015 (vannrett stolpe) |
| X'A1C1' (bølgestrek) | U+301C (bølgestrek) | U+FF5E (Tilde med full bredde) |
| X'A1C2' (dobbelt vertikal linje) | U+2016 (dobbelt vertikal linje) | U+2225 (Parallell til) |
| X'A1DD' (minustegn) | U+2212 (minustegn) | U+FF0D (bindestrek med full bredde) |
| X'8FA2C3' (brutt stolpe) | U+00A6 (brutt stolpe) | U+FFE4 (brutt stolpe med full bredde) |
For eksempel blir tegnet gefirt-tankestrek med CCSID 954-kodeverdien X'A1BD' konvertert til Unicode-kodeverdien U+2014 ved bruk av IBMs konverteringstabell, men til U+2015 ved bruk av Microsofts konverteringstabell. På grunn av denne forskjellen i konverteringen kan du få to ulike kodeverdier for det samme tegnet i en DB2 DB2 UDB Unicode-database, eller i en grafisk kolonne i en DB2 UDB 954-database. Dette kan skape problemer for Microsoft ODBC-applikasjoner fordi de ville behandle U+2014 som en ugyldig kodeverdi. For å unngå disse potensielle problemene har DB2 UDB Microsofts alternative konverteringstabell fra CCSID 954 til Unicode, i tillegg til IBMs standard konverteringstabell. Du må erstatte IBMs standard konverteringstabell med den alternative konverteringstabellen fra Microsoft. Legg merke til at IBMs standard konverteringstabell fra Unicode til CCSID 954 er identisk med Microsofts versjon.
Når du konverterer fra CCSID 954 til Unicode, brukes DB2 Universal Databases standard tabell for kodesettkonvertering. Hvis du vil bruke en annen versjon av konverteringstabellen, for eksempel Microsoft-versjonen, må du manuelt erstatte filen med standard konverteringstabell (.cnv).
Før du erstatter den eksisterende tabellfilen for kodesettkonvertering i katalogen sqllib/conv, må du reservekopiere filen i tilfelle du ønsker å bytte tilbake til den. På UNIX og Linux er katalogen sqllib/conv knyttet til installeringsbanen for DB2 UDB.
For at dette skal fungere, må alle DB2 UDB-klienter som knyttes til den samme CCSID 954-databasen, endre konverteringstabell. Hvis klienten din har japansk Windows, med ANSI-kodesett Shift-JIS (CCSID 943), må du også bytte DB2s standard konverteringstabeller mellom CCSID 943 og Unicode til Microsofts versjon. Ellers kan de ulike klientene lagre det samme tegnet med forskjellige kodeverdier.
Slik erstatter du DB2 UDBs standard konverteringstabell for konvertering fra CCSID 954 til Unicode:
Slik erstatter du DB2 UDBs standard konverteringstabeller for konvertering mellom CCSID 943 og Unicode:
Når du bruker Microsofts japanske Windows Shift-JIS kodesett som er registrert som IBMs CCSID (Coded Character Set Identifier) 943, kan følgende to problemer oppstå ved konvertering av tegn mellom CCSID 943 og Unicode. Dette potensielle problemet skyldes forskjeller mellom IBMs og Microsofts tabeller for kodesettkonvertering. For å unngå disse potensielle problemene har DB2 Universal Database (UDB) Microsofts alternative konverteringstabeller mellom CCSID 943 og Unicode, i tillegg til IBMs standard konverteringstabeller.
Av historiske grunner er over 300 tegn i kodesettet CCSID 943 representert med to eller tre kodeverdier (code points) hver. Bruk av IME-redigeringsprogram og konverteringstabeller for kodesett gjør at bare en av de tilsvarende kodeverdiene blir oppgitt. Eksempel: Romertallet en med små bokstaver ('i') har to tilsvarende kodeverdier: X'EEEF' og X'FA40'. Microsoft Windows IME-programmer genererer alltid X'FA40' når 'i' skrives. Generelt bruker IBM og Microsoft den samme primære kodeverdien for å representere et tegn, bortsett fra for disse 13 tegnene:
| Navn på tegn (Unicode-kodeverdi) | IBM Shift-JIS-primærkodeverdi | Microsoft Shift-JIS-primærkodeverdi |
|---|---|---|
| Romertall en (U+2160) | X'FA4A' | X'8754' |
| Romertall to (U+2161) | X'FA4B' | X'8755' |
| Romertall tre (U+2162) | X'FA4C' | X'8756' |
| Romertall fire (U+2163) | X'FA4D' | X'8757' |
| Romertall fem (U+2164) | X'FA4E' | X'8758' |
| Romertall seks (U+2165) | X'FA4F' | X'8759' |
| Romertall sju (U+2166) | X'FA50' | X'875A' |
| Romertall åtte (U+2167) | X'FA51' | X'875B' |
| Romertall ni (U+2168) | X'FA52' | X'875C' |
| Romertall ti (U+2169) | X'FA53' | X'875D' |
| Parenthesized ideograph stock (U+3231) | X'FA58' | X'FA58' |
| Nummertegn (U+2116) | X'FA59' | X'8782' |
| Telefontegn (U+2121) | X'FA5A' | X'8754' |
IBM-produkter som DB2 UDB bruker primært IBM-kodeverdier, slik som X'FA4A', for å fremstille romertallet en med store bokstaver ('I'), mens Microsoft-produkter bruker X'8754' til å representere samme tegn. En Microsoft ODBC-applikasjon kan sette inn tegnet 'I' som X'8754' i en DB2 UDB-database med CCSID 943, og kontrollsenteret i DB2 UDB kan sette inn samme tegn som X'FA4A' i den samme CCSID 943-databasen. ODBC-applikasjoner finner bare de radene som har 'I' kodet som X'8754', og DB2 UDB Kontrollsenter finner bare radene som har 'I' kodet som X'FA4A'. Hvis du vil gjøre det mulig for DB2 UDB Kontrollsenter å velge 'I' som X'8754', må du bytte ut standardkonverteringstabellene fra IBM mellom CCSID 943 og Unicode med de alternative konverteringstabellene fra Microsoft.
Listen nedenfor viser tegnene, ved konvertering fra CCSID 943 til Unicode, som vil resultere i forskjellig kodeverdi avhengig av hvilken konverteringstabell som blir brukt (IBM eller Microsoft). For disse tegnene følger IBMs konverteringstabell JIS (Japanese Industry Standard) JISX0208, JISX0212 og JISX0221.
| Shift-JIS-kodeverdi (tegnnavn) | IBMs primære kodeverdi (Unicode-navn) | Microsofts primære kodeverdi (Unicode-navn) |
|---|---|---|
| X'815C' (gefirt-tankestrek) | U+2014 (gefirt-tankestrek) | U+2015 (vannrett stolpe) |
| X'8160' (bølgestrek) | U+301C (bølgestrek) | U+FF5E (tilde med full bredde) |
| X'8161' (dobbelt vertikal linje) | U+2016 (dobbelt vertikal linje) | U+2225 (Parallell til) |
| X'817C' (minustegn) | U+2212 (minustegn) | U+FF0D (bindestrek med full bredde) |
| X'FA55' (brutt stolpe) | U+00A6 (brutt stolpe) | U+FFE4 (brutt stolpe med full bredde) |
For eksempel blir tegnet gefirt-tankestrek med CCSID 943-kodeverdien X'815C' konvertert til Unicode-kodeverdien U+2014 ved bruk av IBMs konverteringstabell. Det konverteres imidlertid til U+2015 ved bruk av Microsofts konverteringstabell. På grunn av denne forskjellen i konverteringen kan du få to ulike kodeverdier for det samme tegnet i en DB2 UDB Unicode-database. Dette kan skape problemer for Microsoft ODBC-applikasjoner fordi de ville behandle U+2014 som en ugyldig kodeverdi. For å unngå dette potensielle problemet, må du bytte ut standardkonverteringstabellene fra IBM mellom CCSID 943 og Unicode med de alternative konverteringstabellene fra Microsoft.
Bruk av de alternative konverteringstabellene fra Microsoft mellom CCSID 943 og Unicode bør begrenses til lukkede miljøer hvor alle DB2 UDB UDB-klientene og DB2 UDB-databasene bruker kodesettet CCSID 943 og de samme alternative Microsoft-konverteringstabellene. Hvis du har en DB2 UDB-klient som bruker IBMs standard konverteringstabeller og en annen DB2 UDB-klient som bruker de alternative Microsoft-konverteringstabellene, og begge klientene setter inn data i den samme DB2 UDB-databasen som bruker CCSID 943, kan samme tegn bli lagret med forskjellige kodeverdier i databasen.
Når du konverterer mellom CCSID 943 og Unicode, blir konverteringstabellene for kodesett som er standard i DB2 Universal Database (DB2 UDB) brukt. Hvis du vil bruke en annen versjon av konverteringstabellene, for eksempel Microsoft-versjonen, må du manuelt erstatte filene med standard konverteringstabeller (.cnv).
Før du erstatter de eksisterende tabellfilene for kodesettkonvertering i katalogen sqllib/conv, må du reservekopiere filene i tilfelle du ønsker å bytte tilbake. På UNIX og Linux er katalogen sqllib/conv knyttet til installeringsbanen for DB2 UDB.
For at erstatning av konverteringstabell skal fungere, må alle DB2 UDB-klienter som knyttes til den samme databasen, endre konverteringstabell. Ellers kan de ulike klientene lagre det samme tegnet med forskjellige kodeverdier.
Slik erstatter du DB2 UDBs standard konverteringstabeller for konvertering av tegn mellom CCSID 943 og Unicode:
Selv om det blir nevnt i dokumentasjonen, støttes ikke lenger operativsystemet MVS av DB2 Universal Database. MVS er erstattet med z/OS.
Reservekopierings- og gjenopprettingsoperasjoner til og fra flere magnetbåndstasjoner virker kanskje ikke hvis du bruker Linux 390-operativsystemet.
Når du skal bruke utviklingssenteret i UNIX sammen med Hummingbird Exceed, må XTEST-utvidelsen versjon 2.2 være aktivert før du kan flytte og dokke utsnitt ved å dra tittellinjene deres inne i utviklingssenteret.
Slik aktiverer du XTEST-utvidelsen: