Brukerhåndbok

Programmering i et distribuert miljø

DB2 Connect gir et applikasjonsprogram tilgang til data i DB2-databaser på System/390- og AS/400-tjenere. En applikasjon som kjører på Windows, kan for eksempel få tilgang til data i en DB2 Universal Database for OS/390-database. Du kan opprette nye applikasjoner eller endre eksisterende applikasjoner som skal kjøre i et vertsmaskin- eller AS/400-miljø. Du kan også utvikle applikasjoner i et miljø og konvertere dem til et annet miljø.

Med DB2 Connect kan du bruke APIene nedenfor sammen med vertsdatabaseprodukter, for eksempel DB2 Universal Database for OS/390, så lenge vertsdatabaseproduktet støtter APIen:

Noen SQL-setninger er forskjellige i de ulike relasjonsdatabaseproduktene. Du kan støte på SQL-setninger som er

SQL-setninger i de to første kategoriene kan lett brukes i flere miljøer, men setningene i den tredje kategorien må endres først. Generelt sett kan ikke SQL-setninger i datadefinisjonsspråk (DDL) brukes i like mange miljøer som SQL-setningene i datahåndteringsspråk (DML).

DB2 Connect godtar noen SQL-setninger som DB2 Universal Database ikke støtter. DB2 Connect videresender disse setningene til verts- eller AS/400-tjeneren. Hvis du ønsker flere opplysninger om begrensningene på de ulike plattformene, for eksempel maksimal kolonnelengde, kan du slå opp i SQL Reference.

Hvis du flytter en CICS-applikasjon fra OS/390 eller VSE for å kjøre det under et annet CICS-produkt (for eksempel CICS for AIX), kan den også få tilgang til OS/390- eller VSE-databasen ved hjelp av DB2 Connect. Slå opp i håndboken CICS/6000 Application Programming Guide og CICS Customization and Operation hvis du ønsker flere opplysninger.

Når du programmerer i et vertsmaskin- eller AS/400-miljø, bør du vurdere disse faktorene:

Bruke datadefinisjonsspråk (DDL)

DDL-setninger er forskjellige i de ulike IBM-databaseproduktene fordi lageret blir håndtert forskjellig på ulike systemer. På verts- eller AS/400-tjenere kan det være flere trinn fra du definerer en database til du utsteder en CREATE TABLE-setning. En serie med setninger kan for eksempel konvertere utformingen av logiske objekter til en fysisk fremstilling av disse objektene i lageret.

Forkompilatoren videresender mange slike DDL-setninger til verts- eller AS/400-tjeneren når du forkompilerer til en database på vertsmaskinen eller AS/400-tjeneren. De samme setningene blir ikke forkompilert mot en database på systemet der applikasjonen kjører. I en OS/2-applikasjon blir for eksempel CREATE STORGROUP-setningen forkompilert til en DB2 Universal Database for OS/390-database, men ikke til en DB2 for OS/2-database.

Bruke datahåndteringsspråk (DML)

Generelt sett kan DML-setninger brukes i flere miljøer. SELECT-, INSERT-, UPDATE- og DELETE-setninger er like for alle IBMs relasjonsdatabaseprodukter. De fleste applikasjoner bruker primært DML SQL-setninger, som DB2 Connect støtter.

Numeriske datatyper

Når numeriske data blir overført til DB2 Universal Database, kan datatypen bli endret. SQLTYPE-verdier av typen numeriske data og sonede desimaldata (støttet av DB2 Universal Database for AS/400) blir konvertert til SQLTYPE-verdier av typen faste (pakkede) desimaldata.

Data med blandede byte

Data med blandede byte kan bestå av tegn fra et tegnsett med utvidet UNIX-kode (EUC), et dobbeltbytetegnsett (DBCS) og et enkeltbytetegnsett (SBCS) i den samme kolonnen. På systemer som lagrer data i EBCDIC (OS/390, OS/400, VSE og VM), merker skiftut- og skiftinntegnene starten og slutten på dobbeltbytedata. På systemer som lagrer data i ASCII-format (for eksempel OS/2 og UNIX), er det ikke nødvendig med skiftinn- og skiftuttegn.

Hvis applikasjonen overfører data med blandede byte fra et ASCII-system til et EBCDIC-system, må du gi skifttegnene nok plass. Tilføy 2 byte til datalengden for hver konvertering fra SBCS- til DBCS-data. Hvis du ønsker kompatibilitet med flere miljøer, bør du bruke strenger med variabel lengde i applikasjoner som bruker data med blandede byte.

Lange felt

Lange felt (strenger som er lengre enn 254 tegn) blir behandlet forskjellig på ulike systemer. Det kan hende at en verts- eller AS/400-tjener bare støtter en undergruppe av skalarfunksjonene for lange felt. DB2 Universal Database for OS/390 støtter for eksempel bare funksjonene LENGTH og SUBSTR for lange felt. I tillegg kan en verts- eller AS/400-tjener ha ulik behandling av enkelte SQL-setninger. DB2 for VSE & VM har for eksempel begrensningen at INSERT-setningen bare kan bruke vertsvariabelen SQLDA eller verdien Null.

Datatypen stort objekt (LOB)

DB2 Connect støtter LOB-datatypen.

Brukerdefinerte typer (UDT)

DB2 Connect støtter bare brukerdefinerte distinkte typer. Det støtter ikke abstrakte datatyper.

Datatypen ROWID

DB2 Connect behandler ROWID-datatypen som VARCHAR for bitdata.

Datatypen 64-biters heltall (BIGINT)

DB2 Connect støtter heltall med åtte byte (64-biter). Den interne datatypen BIGINT gir støtte for kardinalitet av veldig store databaser, samtidig som datapresisjonen blir bevart.

Bruke datastyrespråk (DCL)

De enkelte styresystemene for relasjonsdatabaser fra IBM har ulike grader for SQL-setningene GRANT og REVOKE. Slå opp i publikasjonene for de enkelte produktene for å kontrollere hvilken SQL-setning du bør bruke for de enkelte databasesystemene.

Tilkoble og frakoble

DB2 Connect støtter CONNECT TO- og CONNECT RESET-versjonen av CONNECT-setningen, samt CONNECT uten noen parametere. Hvis en applikasjon anroper en SQL-setning uten å utføre en eksplisitt CONNECT TO-setning først, blir det utført en implisitt tilkobling til standardapplikasjonstjeneren (hvis det er definert en).

Når du kobler deg til en database, blir informasjon som identifiserer styresystemet for relasjonsdatabasen, returnert i SQLERRP-feltet for SQLCA. Hvis applikasjonstjeneren er en IBM-relasjonsdatabase, inneholder de første tre bytene i SQLERRP en av disse verdiene:

DSN
DB2 Universal Database for OS/390

ARI
DB2 for VSE & VM

QSQ
DB2 Universal Database for AS/400

SQL
DB2 Universal Database.

Hvis du utsteder en CONNECT TO- eller null CONNECT-setning mens du bruker DB2 Connect, blir landkode- eller områdesymbolet i SQLERRMC-feltet for SQLCA returnert som blanktegn. IDen for kodet tegnsett (CCSID) for applikasjonstjeneren blir returnert i kodesettsymbolet.

Du kan eksplisitt frakoble ved hjelp av CONNECT RESET-setningen (for type 1 connect), RELEASE- og COMMIT-setningen (for type 2 connect) eller DISCONNECT-setningen (begge typene connect-setninger, men ikke i et TP-overvåkermiljø).

Hvis en tilkobling ikke blir eksplisitt frakoblet og applikasjonen avsluttes på en normal måte, iverksetter DB2 Connect resultatdataene implisitt.
Merk:En applikasjon kan motta SQLCODE-verdier som angir feil, og likevel bli avsluttet på normal måte. I dette tilfellet iverksetter DB2 Connect dataene. Hvis du ikke vil at dataene skal iverksettes, må du utføre en ROLLBACK-kommando.

Med FORCE-kommandoen kan du frakoble valgte brukere eller alle brukerne fra databasen. Databaser på verts- eller AS/400-tjenere har støtte for dette alternativet. Brukeren kan tvinges av DB2 Connect-arbeidsstasjonen.

Forkompilere

Det er enkelte forskjeller i forkompilatorene blandt de ulike IBM-relasjonsdatabasesystemene. Forkompilatoren for DB2 Universal Database er forskjellig fra forkompilatoren til verts- eller AS/400-tjeneren på følgende måter:

Blokking

DB2 Connect støtter bindingsalternativene for blokking for DB2-databasesystemet:

UNAMBIG
Bare utvetydige pekere blir blokket (standard).

ALL
Tvetydige pekere blir blokket.

NO
Pekere blir ikke blokket.

DB2 Connect bruker blokkstørrelsen som er definert i konfigurasjonsfilen for DB2-databasesystemet i RQRIOBLK-feltet. De gjeldende versjonene av DB2 Connect støtter blokkstørrelser opptil 32 767. Hvis det blir oppgitt større verdier i konfigurasjonsfilen for DB2-databasesystemet, bruker DB2 Connect verdien 32 767, men konfigurasjonsfilen for DB2-databasesystemet tilbakestilles ikke. Blokking blir håndtert på samme måte med den samme blokkstørrelsen for dynamisk og statisk SQL.
Merk:De fleste vertssystemer eller AS/400-tjenere oppfatter dynamiske pekere som tvetydige, men DB2 Universal Database-systemer oppfatter noen dynamiske pekere som utvetydige. Hvis du vil unngå forvirring, kan du oppgi BLOCKING ALL med DB2 Connect.

Oppgi blokkstørrelsen i konfigurasjonsfilen for DB2-databasesystemet ved hjelp av kommandolinjebehandleren (CLP), kontrollsenteret eller en API, som er beskrevet i Administrative API Reference og Command Reference.

Pakkeattributter

En pakke har disse attributtene:

Samlings-ID
IDen til pakken. Den kan oppgis i PREP-kommandoen.

Eier
Autorisasjons-IDen til pakkeeieren. Den kan oppgis i kommandoen PREP eller BIND.

Oppretter
Bruker-IDen som binder pakken.

Kvalifikator
Den implisitte kvalifikatoren for objektene i pakken. Den kan oppgis i kommandoen PREP eller BIND.

De enkelte vertssystemene eller AS/400-tjenerne har begrensninger på bruken av disse attributtene:

DB2 Universal Database for OS/390
Alle de fire attributtene kan være ulike. Hvis du skal bruke en annen kvalifikator, må du ha administrative rettigheter. Du finner flere opplysninger om betingelsene som gjelder bruken av disse attributtene, i Command Reference for DB2 Universal Database for OS/390.

DB2 for VSE & VM
Alle attributtene må være identiske. Hvis BRUKER1 oppretter en bindingsfil (med PREP) og BRUKER2 utfører selve bindingen, behøver BRUKER2 DBA-autorisasjon til binding for BRUKER1. Bare bruker-IDen til BRUKER1 blir brukt i attributtene.

DB2 Universal Database for AS/400
Kvalifikatoren oppgir samlingsnavnet. Forholdet mellom kvalifikatorene og eierforhold påvirker hvem som blir tildelt og fratatt rettigheter til objektet. Bruker-IDen som logger seg på, er oppretter og eier med mindre den er kvalifisert av en samlings-ID. Da er samlings-IDen eier. Samlings-IDen må finnes fra før hvis den blir brukt som en kvalifikator.

DB2 Universal Database
Alle de fire attributtene kan være ulike. Hvis en annen eier skal brukes, er det nødvendig med administrativ adgang, og binderen må ha CREATEIN-rettighet til skjemaet (hvis det finnes fra før).
Merk:DB2 Connect har støtte for kommandoen SET CURRENT PACKAGESET for DB2 Universal Database for OS/390 og DB2 Universal Database.

C-strenger avsluttet med nulltegn

CNULREQD-bindingsalternativet overstyrer behandlingen av strenger med avsluttende nulltegn som er oppgitt ved hjelp av LANGLEVEL-alternativet.

Hvis du vil vite hvordan strenger som er avsluttet med nulltegn, blir behandlet når de er klargjort ved at LANGLEVEL-alternativet er satt til MIA eller SAA1, leser du Application Development Guide.

Standardverdien er at CNULREQD er satt til Ja (YES). Dette fører til at strenger med avsluttende nulltegn blir tolket i henhold til MIA-standarder. Hvis du kobler deg til en DB2 Universal Database for OS/390-tjener, anbefaler vi på det sterkeste at du setter CNULREQD til Ja (YES). Du må binde applikasjoner som er kodet til SAA1-standarder (når det gjelder strenger med avsluttende nulltegn), med CNULREQD-alternativet satt til Nei (NO). Ellers blir strenger med avsluttende nulltegn tolket i henhold til MIA-standarder, selv om de blir klargjort ved at LANGLEVEL blir satt til SAA1.

Frittstående SQLCODE og SQLSTATE

Frittstående SQLCODE- og SQLSTATE-variabler, som er definert i ISO/ANS SQL92, støttes gjennom forkompileringsalternativet LANGLEVEL SQL92E. Det blir utstedt en SQL0020W-advarsel under forkompileringen, som angir at LANGLEVEL ikke er støttet. Denne advarselen gjelder bare funksjonene som står oppført under LANGLEVEL MIA i Command Reference, som er en undergruppe av LANGLEVEL SQL92E.

Definere en sorteringsrekkefølge

Forskjellene mellom EBCDIC og ASCII fører til forskjeller i sorteringsrekkefølgene i de ulike databaseproduktene, og de påvirker også ORDER BY- og GROUP BY-ledd. En måte å minimere disse forskjellene på, er ved å opprette en brukerdefinert rangfølge som etterlikner EBCDIC-sorteringsrekkefølgen. Du kan bare oppgi en rangfølge når du oppretter en ny database. Du finner flere opplysninger om dette i Application Development Guide, Administrative API Reference og Command Reference.
Merk:Databasetabeller kan nå lagres i DB2 Universal Database for OS/390, i ASCII-format. Dette tillater hurtigere dataoverføring mellom DB2 Connect og DB2 Universal Database for OS/390, og fjerner behovet for feltprosedyrer, som ellers brukes til å konvertere data og endre rekkefølgen på dem.

Styre referanseintegritet

Ulike systemer håndterer referansebegrensninger på ulike måter:

DB2 Universal Database for OS/390
Det må opprettes en indeks for en primærnøkkel før det kan opprettes en fremmednøkkel ved hjelp av primærnøkkelen. Tabellene kan referere til seg selv.

DB2 for VSE & VM
Det blir automatisk opprettet en indeks for en fremmednøkkel. Tabellene kan ikke referere til seg selv.

DB2 Universal Database for AS/400
Det blir automatisk opprettet en indeks for en fremmednøkkel. Tabellene kan referere til seg selv.

DB2 Universal Database
For DB2 Universal Database-databaser blir det automatisk opprettet en indeks for en entydig begrensning, inkludert en primærnøkkel. Tabellene kan referere til seg selv.

Andre regler kan ha ulike nivåer av overlapping.

Låsing

Måten databasetjeneren utfører låsing på, kan påvirke noen applikasjoner. Applikasjoner som bruker radnivålåsing, og isolasjonsnivået for pekerstabilitet kan for eksempel ikke uten videre brukes direkte på systemer som utfører sidenivålåsing. På grunn av disse underliggende forskjellene kan det hende at noen applikasjoner må justeres.

DB2 Universal Database for OS/390 og DB2 Universal Database kan tidsutkoble en lås og sende en returkode om feil til ventende applikasjoner.

Forskjeller i SQLCODE- og SQLSTATE-verdier

De ulike relasjonsdatabaseproduktene til IBM gir ikke alltid samme SQLCODE-verdi for samme feil. Du kan løse dette problemet på to måter:

Bruke systemkataloger

Systemkatalogene kan variere i de ulike IBM-databaseproduktene. Mange forskjeller kan maskeres ved å bruke utsnitt. Du finner flere opplysninger om dette emnet i dokumentasjonen for databasetjeneren du bruker.

Katalogfunksjonene i CLI omgår dette problemet ved å ha støtte for den samme APIen og de samme resultatsettene for katalogspørringer i hele DB2-familien.

Overflyt ved numerisk konvertering under hentetildelinger

Det kan hende at de ulike IBM-relasjonsdatabaseproduktene behandler overflyt ved numerisk konvertering under hentetildelinger på forskjellige måter. Tenk deg at du skal hente en flytekolonne inn i en heltallsvertsvariabel fra DB2 Universal Database for OS/390 og fra DB2 Universal Database. Når du konverterer flytetallverdien til en heltallsverdi, kan det oppstå overflyt. Standardverdien er at DB2 Universal Database for OS/390 returnerer en SQLCODE-advarsel og en nullverdi til applikasjonen. DB2 Universal Database returnerer derimot en feil ved konverteringsoverflyt. Applikasjoner bør unngå overflyt ved numerisk konvertering under hentetildelinger ved å hente dataene inn i vertsvariabler med riktig størrelse.

Isolasjonsnivåer

DB2 Connect godtar disse isolasjonsnivåene når du klargjør eller binder en applikasjon:

RR
Gjentakende lesing

RS
Lesestabilitet

CS
Pekerstabilitet

UR
Ikke-iverksatt lesing

NC
Ingen iverksetting

Isolasjonsnivåene blir vist i rekkefølge fra mest beskyttelse til minst beskyttelse. Hvis verts- eller AS/400-tjeneren ikke støtter isolasjonsnivået du oppgir, blir det nest høyeste støttede nivået brukt.

I Tabell 2 ser du resultatene av hvert enkelt isolasjonsnivå på verts- eller AS/400-applikasjonstjeneren.

Tabell 2. Isolasjonsnivåer
DB2 Connect DB2 Universal Database for OS/390 DB2 for VSE & VM DB2 Universal Database for AS/400 DB2 Universal Database
RR RR RR merknad 1 RR
RS merknad 2 RR COMMIT(*ALL) RS
CS CS CS COMMIT(*CS) CS
UR merknad 3 CS COMMIT(*CHG) UR
NC merknad 4 merknad 5 COMMIT(*NONE) UR

Merknader:

  1. Det finnes ikke noe COMMIT-alternativ som tilsvarer RR i DB2 Universal Database for AS/400. DB2 Universal Database for AS/400 støtter RR ved å låse hele tabellen.

  2. Resulterer i RR for versjon 3.1 og resulterer i RS for versjon 4.1 med APAR PN75407 eller versjon 5.1.

  3. Resulterer i CS for versjon 3.1 og resulterer i UR for versjon 4.1 eller versjon 5.1.

  4. Resulterer i CS for versjon 3.1 og resulterer i UR for versjon 4.1 med APAR PN60988 eller versjon 5.1.

  5. DB2 for VSE & VM støtter ikke isolasjonsnivået NC.

Med DB2 Universal Database for AS/400 kan du få tilgang til en ikke-journalført tabell hvis en applikasjon er bundet med isolasjonsnivået UR og blokking er satt til ALL, eller hvis isolasjonsnivået er NC.

Lagrede prosedyrer

Stored Procedure Builder

DB2 Stored Procedure Builder har et brukervennlig miljø for å opprette, installere og teste lagrede prosedyrer. På denne måten kan du konsentrere deg om å opprette logikken for de lagrede prosedyrene dine i stedet for om detaljene ved å registrere, bygge og installere lagrede prosedyrer på en DB2-tjener. I tillegg kan du bruke Stored Procedure Builder til å utvikle lagrede prosedyrer på ett operativsystem og bygge dem på et annet tjeneroperativsystem.

Stored Procedure Builder er en grafisk applikasjon som støtter svært hurtig utvikling. Ved hjelp av Stored Procedure Builder kan du utføre disse oppgavene:

Du kan starte Stored Procedure Builder som en egen applikasjon fra programgruppen DB2 Universal Database, eller fra en disse utviklingsapplikasjonene:

Du kan også starte Stored Procedure Builder fra Kontrollsenter for DB2 for OS/390. Du kan starte Stored Procedure Builder som en egen prosess fra menyen Verktøy i Kontrollsenter, verktøylinjen eller mappen Lagrede prosedyrer. Fra vinduet Stored Procedure Builder kan du i tillegg eksportere en eller flere valgte lagrede SQL-prosedyrer som er bygd for en DB2 for OS/390-tjener, til en oppgitt fil som kan kjøre i Kommandolinjebehandler (CLP).

Stored Procedure Builder administrerer arbeidet ditt ved hjelp av Prosjekter. De enkelte Stored Procedure Builder-prosjektene lagrer tilkoblinger til bestemte databaser, for eksempel DB2 for OS/390-tjenere. I tillegg kan du opprette filtre for å vise undergrupper av de lagrede prosedyrene for de enkelte databasene. Når du åpner et nytt eller eksisterende Stored Procedure Builder-prosjekt, kan du bruke et filter på lagrede prosedyrer slik at du viser dem basert på navnet, skjemaet, språket eller samlings-IDen (bare for OS/390).

Det blir lagret tilkoblingsinformasjon i et Stored Procedure Builder-prosjekt, så når du åpner et eksisterende prosjekt, blir du automatisk bedt om å oppgi bruker-ID og passord for databasen. Ved hjelp av veiviseren Inserting SQL Stored Procedure kan du bygge lagrede SQL-prosedyrer på en DB2 for OS/390-tjener. For en lagret SQL-prosedyre som er bygd til en DB2 for OS/390-tjener, kan du definere alternativer for kompilering, forlink, link, binding, kjøretid, WLM-miljø og ekstern sikkerhet.

I tillegg kan du hente SQL-kostnadsinformasjon om den lagrede SQL-prosedyren, for eksempel informasjon om CPU-tid og annen DB2-kostnadsinformasjon om tråden som den lagrede SQL-prosedyren kjører på. Du kan i tillegg hente kostnadsinformasjon om ventetid ved låsekonflikt, antall hentesider, antall lese-I/Uer og antall skrive-I/Uer.

Kostnadsinformasjonen blir hentet ved at Stored Procedure Builder kobler seg til en DB2 for OS/390-tjener, utfører SQL-setningen og anroper en lagret prosedyre (DSNWSPM) for å finne ut hvor mye CPU-tid den lagrede SQL-prosedyren brukte.

Ikke-enhetlig sammensatt SQL

Med sammensatt SQL kan du gruppere flere SQL-setninger i en enkelt utførbar blokk. Dette kan redusere nettverksbelastningen og forbedre svartiden.

DB2 Connect støtter ikke-enhetlig sammensatt SQL. Dette betyr at behandlingen av sammensatt SQL fortsetter selv om det oppstår en feil. (Med enhetlig sammensatt SQL, som ikke er støttet av DB2 Connect, tilbakestiller en feil hele gruppen med sammensatt SQL.)

Utføringen av setninger fortsetter helt til de blir avbrutt av applikasjonstjeneren. Generelt sett blir utføringen av den sammensatte SQL-setningen bare stoppet hvis det oppstår alvorlige feil.

Ikke-enhetlig sammensatt SQL kan brukes sammen med alle verts- eller AS/400-applikasjonstjenerne som er støttet.

Hvis det oppstår flere SQL-feil, blir SQLSTATE-verdiene for de sju første mislykkede setningene returnert i SQLERRMC-feltet for SQLCA med en melding om at det oppstod flere feil. Du finner flere opplysninger i SQL Reference.

Flerstedsoppdatering med DB2 Connect

Med DB2 Connect kan du utføre en flerstedsoppdatering, også kalt en tofaseiverksetting. En flerstedsoppdatering er en oppdatering av flere databaser i en enkelt distribuert arbeidsenhet (DUOW). Det er flere faktorer som avgjør om du kan bruke denne funksjonen:

SQL-setninger for verts- eller AS/400-tjenere som er støttet av DB2 Connect

Disse setningene blir kompilert under behandling på verts- eller AS/400-tjenere, men ikke på DB2 Universal Database-systemer:

Kommandolinjebehandleren har også støtte for disse setningene.

Disse setningene er støttet for behandling på verts- eller AS/400-tjenere, men de blir ikke føyd til bindingsfilen eller pakken, og de er ikke støttet av kommandolinjebehandleren:

Forkompilatoren går ut fra følgende:

SQL-setninger for verts- eller AS/400-tjenere som blir avvist av DB2 Connect

Disse SQL-setningene er ikke støttet av DB2 Connect og ikke støttet av kommandolinjebehandleren:

Utvidede dynamiske SQL-setninger for DB2 for VSE & VM blir avvist med -104 og SQLCODE-koder for syntaksfeil.


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