Met DB2 Connect kan een toepassingsprogramma toegang krijgen tot gegevens in DB2-databases op System/390- of AS/400-servers. Een op Windows uitgevoerde toepassing kan bijvoorbeeld toegang krijgen tot gegevens in een DB2 Universal Database for OS/390-database. Nieuwe toepassingen kunnen worden gemaakt of bestaande toepassingen kunnen worden uitgevoerd in een host- of AS/400-omgeving. U kunt ook toepassingen ontwikkelen in een bepaalde omgeving en deze vervolgens overdragen aan een andere omgeving.
Met DB2 Connect kunnen de volgende API's worden gebruikt met host-databaseproducten zoals DB2 Universal Database for OS/390, mits de betreffende API wordt ondersteund door het host-databaseproduct:
Een aantal SQL-instructies is verschillend voor de verschillende relationele-databaseproducten. U kunt de volgende categorieën SQL-instructies tegenkomen:
De SQL-instructies in de eerste twee categorieën zijn goed over te dragen, maar de instructies in de derde categorie moeten eerst worden gewijzigd. In het algemeen zijn SQL-instructies in de programmeertaal DDL (Data Definition Language) minder goed overdraagbaar dan instructies in DML (Data Manipulation Language).
DB2 Connect accepteert een aantal SQL-instructies die niet worden ondersteund door DB2 Universal Database. DB2 Connect geeft deze instructies door aan de host- of AS/400-server. Raadpleeg SQL Reference voor informatie over de maximale waarden op verschillende platforms, zoals bijvoorbeeld de maximale kolomlengte.
Als een CICS-toepassing eerst wordt uitgevoerd onder OS/390 of VSE en vervolgens onder een ander CICS-product (bijvoorbeeld CICS for AIX), kan deze met behulp van DB2 Connect ook toegang krijgen tot de OS/390- of VSE-database. Raadpleeg de handleidingen CICS/6000 Application Programming Guide en CICS Customization and Operation voor meer bijzonderheden.
Bij het programmeren in een host- of AS/400-omgeving moet u rekening houden met de volgende factoren:
DDL-instructies zijn verschillend voor de uiteenlopende IBM-databaseproducten omdat de opslag niet op dezelfde manier plaatsvindt op de verschillende systemen. Op host- of AS/400-serversystemen moeten mogelijk verschillende stappen worden doorlopen voor het ontwerpen van een database en het opgeven van de instructie CREATE TABLE. Met een aantal instructies kan bijvoorbeeld het ontwerp van logische objecten worden omgezet in een fysieke weergave van de desbetreffende objecten in het geheugen.
De precompiler geeft veel van deze DDL-instructies door aan de host- of AS/400-server bij het precompileren naar een host- of AS/400-serverdatabase. Deze instructies worden niet geprecompileerd als een database op het systeem staat waarop de toepassing wordt uitgevoerd. Bij een OS/2-toepassing wordt bijvoorbeeld de instructie CREATE STORGROUP correct geprecompileerd naar een DB2 Universal Database for OS/390-database, maar niet naar een DB2-database voor OS/2.
In het algemeen zijn DML-instructies gemakkelijk over te dragen. De instructies SELECT, INSERT, UPDATE en DELETE zijn gelijk voor alle relationele-databaseproducten van IBM. De meeste toepassingen maken vooral gebruik van DML-instructies, die worden ondersteund door DB2 Connect.
Als numerieke gegevens worden overgebracht naar DB2 Universal Database, wordt mogelijk het gegevenstype gewijzigd. SQLTYPE's die numeriek zijn of een niet-gecomprimeerde decimaalindeling hebben (ondersteund door DB2 Universal Database for AS/400), worden omgezet in een gecomprimeerde decimaalindeling.
Gemengde gegevens kunnen tekens bevatten uit de tekenset EUC (extended UNIX code), de dubbelbytetekenset (DBCS) of de enkelbytetekenset (SBCS). Op systemen waarbij gegevens worden opgeslagen in EBCDIC (OS/390, OS/400, VSE en VM), wordt het begin- en eindpunt van dubbelbytegegevens aangegeven met behulp van shift-out- en shift-in-tekens. Op systemen waarbij gegevens worden opgeslagen in ASCII (zoals OS/2 en UNIX) zijn de shift-in- en shift-out-tekens niet nodig.
Als de toepassing gemengde gegevens overdraagt van een ASCII-systeem naar een EBCDIC-systeem, moet u ervoor zorgen dat er voldoende ruimte beschikbaar is voor de shift-tekens. Voor elke overdracht van SBCS- naar DBCS-gegevens, moet u twee bytes optellen bij de gegevenslengte. Voor een betere overdraagbaarheid kunt u reeksen met variabele lengte gebruiken die gebruikmaken van gemengde gegevens.
Lange velden (reeksen met meer dan 254 tekens) worden op verschillende wijze verwerkt op de uiteenlopende systemen. Mogelijk ondersteunt de host- of AS/400-server slechts een aantal scalaire functies voor lange velden. Bij DB2 Universal Database for OS/390 zijn bijvoorbeeld alleen de functies LENGTH en SUBSTR toegestaan voor lange velden. Het is tevens mogelijk dat bepaalde SQL-instructies bij een host- of AS/400-server op verschillende manieren moeten worden verwerkt. Bij DB2 for VSE & VM is het bijvoorbeeld vereist dat voor de instructie INSERT alleen een hostvariabele, de SQLDA of een nullwaarde wordt gebruikt.
LOB-gegevens worden ondersteund door DB2 Connect.
Alleen UDT's van het type DISTINCT worden ondersteund door DB2 Connect. Het gegevenstype Abstract wordt niet ondersteund.
Het gegevenstype ROWID wordt door DB2 Connect verwerkt als VARCHAR voor bitgegevens.
Integers van acht bytes (64-bits) worden ondersteund door DB2 Connect. Het interne gegevenstype BIGINT wordt gebruikt voor de ondersteuning van de kardinaliteit van zeer grote databases, waarbij de nauwkeurigheid van de gegevens behouden blijft.
Elk relationeel databasebeheersysteem (RDBMS) van IBM heeft verschillende granulatieniveaus voor de SQL-instructies GRANT en REVOKE. Controleer de desbetreffende publicaties om de juiste SQL-instructies voor elk databasebeheersysteem te controleren.
DB2 Connect ondersteunt de versies CONNECT TO en CONNECT RESET van de CONNECT-instructie, evenals CONNECT zonder parameters. Als een toepassing een SQL-instructie aanroept zonder eerst een expliciete instructie CONNECT TO uit te voeren, wordt een impliciete CONNECT uitgevoerd op de standaard toepassingenserver (indien deze is gedefinieerd).
Als u een verbinding met een database tot stand brengt, wordt de informatie waarmee het relationele databasebeheersysteem wordt geïdentificeerd, teruggezonden in het SQLERRP-veld van de SQLCA. Als de toepassingenserver een relationele database van IBM is, worden de eerste drie bytes van het SQLERRP-veld gevormd door:
Als u een CONNECT TO of null-CONNECT opgeeft terwijl u gebruikmaakt van DB2 Connect, wordt de landaanduiding in het veld SQLERRMC van SQLCA blanco teruggezonden; het CCSID van de toepassingenserver wordt teruggezonden in de codetabel of codeset.
U kunt de verbinding expliciet verbreken met de instructie CONNECT RESET (verbindingstype 1), de instructies RELEASE en COMMIT (verbindingstype 2) of de instructie DISCONNECT (beide typen, behalve in een TP-monitoromgeving).
Als een verbinding niet expliciet wordt verbroken en de toepassing op normale wijze wordt beëindigd, voert DB2 Connect impliciet een COMMIT uit op de resultaatgegevens.
Opmerking: | Een toepassing kan SQLCODE's ontvangen die fouten aangeven en toch op de normale wijze worden beëindigd. DB2 Connect voert in deze gevallen een COMMIT uit op de gegevens. Als u niet wilt dat er een COMMIT wordt uitgevoerd op de gegevens, moet u de opdracht ROLLBACK opgeven. |
Met de opdracht FORCE kunnen bepaalde gebruikers of alle gebruikers worden losgekoppeld van de database. Dit wordt ondersteund voor host- of AS/400-serverdatabases. De gebruiker kan van het DB2 Connect-werkstation worden verwijderd.
Er zijn een aantal verschillen tussen de precompilers voor de verschillende relationele databasesystemen van IBM. De precompiler voor DB2 Universal Database vertoont de volgende verschillen ten opzichte van precompilers voor host- of AS/400-servers:
DB2 Connect ondersteunt de bindopties van DB2 Database Manager voor het samenvoegen van rijen in een blok:
DB2 Connect maakt gebruik van de in het configuratiebestand van DB2 Database Manager gedefinieerde blokgrootte voor het RQRIOBLK-veld. De huidige versies van DB2 Connect ondersteunen blokgroottes tot 32 767. Als grotere waarden worden opgegeven in het configuratiebestand van DB2 Database Manager, gebruikt DB2 Connect de waarde van 32 767, maar stelt het configuratiebestand van DB2 Database Manager niet opnieuw in. BLOCKING wordt op dezelfde manier uitgevoerd met dezelfde blokgrootte voor dynamische en statische SQL-instructies.
Opmerking: | De meeste host- of AS/400-serversystemen beschouwen dynamische cursors als ambigu, maar DB2 Universal Database-systemen beschouwen sommige dynamische cursors als niet-ambigu. Om verwarring te voorkomen kunt u bij DB2 Connect BLOCKING ALL opgeven. |
Geef de blokgrootte op in het configuratiebestand van DB2 Database Manager met behulp van de Opdrachtregelinterface (CLP), Besturingscentrum of een API, zoals beschreven in Administrative API Reference en Command Reference.
Een pakket heeft de volgende kenmerken:
Alle host- of AS/400-serversystemen hebben beperkingen bij het gebruik van de volgende kenmerken:
Opmerking: | DB2 Connect biedt ondersteuning voor de opdracht SET CURRENT PACKAGESET voor DB2 Universal Database for OS/390 en DB2 Universal Database. |
De bindoptie CNULREQD schakelt de verwerking uit van de op null eindigende reeksen die zijn opgegeven met de optie LANGLEVEL.
Zie de Application Development Guide voor een beschrijving van de verwerking van op null eindigende reeksen die zijn opgegeven met de optie LANGLEVEL ingesteld op MIA of SAA1.
Standaard wordt CNULREQD ingesteld op YES. Dit zorgt ervoor dat de op null eindigende reeksen worden omgezet volgens de MIA-normen. Als een verbinding met een DB2 Universal Database for OS/390-server tot stand wordt gebracht, wordt het ten sterkste aangeraden CNULREQD in te stellen op YES. Als u een bind uitvoert op volgens SAA1-normen (met betrekking tot de op null eindigende reeksen) gecodeerde toepassingen, moet u ervoor zorgen dat de optie CNULREQD is ingesteld op NO. Als dit niet het geval is, worden de op null eindigende reeksen omgezet volgens de MIA-normen, zelfs als de reeksen zijn opgegeven met de optie LANGLEVEL ingesteld op SAA1.
De zelfstandige variabelen SQLCODE en SQLSTATE, zoals gedefinieerd in ISO/ANS SQL92, worden ondersteund met de precompilatieoptie LANGLEVEL SQL92E. Een SQL0020W-waarschuwing wordt verzonden tijdens het precompileren, waarmee wordt aangegeven dat LANGLEVEL niet wordt ondersteund. Deze waarschuwing geldt alleen voor de functies die in de lijst onder LANGLEVEL MIA staan in Command Reference. Dit is een onderdeel van LANGLEVEL SQL92E.
De verschillen tussen EBCDIC en ASCII veroorzaken verschillen in de sorteervolgorde van de verschillende databaseproducten en hebben ook invloed op de clausules ORDER BY en GROUP BY. Een manier om deze verschillen te minimaliseren, is het maken van een door de gebruiker gedefinieerde sorteervolgorde, die de sorteervolgorde van EBCDIC nabootst. U kunt uitsluitend een sorteervolgorde opgeven als u een nieuwe database maakt. Zie de Application Development Guide, de Administrative API Reference en de Command Reference voor meer informatie.
Opmerking: | Databasetabellen kunnen nu in ASCII-indeling worden opgeslagen in DB2 Universal Database for OS/390. Hierdoor kunnen gegevens sneller worden uitgewisseld tussen DB2 Connect en DB2 Universal Database for OS/390. Bovendien is het niet langer noodzakelijk veldprocedures te leveren voor het converteren en opnieuw sorteren van gegevens. |
De verschillende systemen verwerken verwijzingsvoorwaarden op verschillende manieren:
Andere regels verschillen voor wat betreft het overlappende niveau.
De manier waarop de databaseserver de vergrendeling uitvoert, beïnvloedt sommige toepassingen. Toepassingen die bijvoorbeeld zijn ontworpen voor vergrendeling op rijniveau en het vergrendelingsniveau van de cursorstabiliteit, zijn niet direct te gebruiken op systemen die vergrendeling op paginaniveau uitvoeren. Vanwege deze onderliggende verschillen is het mogelijk dat de toepassingen moeten worden aangepast.
Bij DB2 Universal Database for OS/390 en DB2 Universal Database kan een time-out op een vergrendeling worden uitgevoerd en kan een foutretourcode worden verstuurd aan wachtende toepassingen.
De verschillende relationele databaseprogramma's van IBM produceren niet altijd dezelfde SQLCODE's voor vergelijkbare fouten. U kunt dit probleem op een van de volgende twee manieren verhelpen:
SQLSTATE's hebben ongeveer dezelfde betekenis in de verschillende databaseproducten, en de producten maken SQLSTATE's die overeenkomen met SQLCODE's.
DB2 Connect wijst standaard SQLCODE's en tokens van elk host- of AS/400-serversysteem van IBM toe aan het DB2 Universal Database-systeem. U kunt uw eigen SQLCODE-toewijzingsbestand opgeven, als u de standaardtoewijzing wilt uitschakelen of als u gebruikmaakt van een databaseserver die geen SQLCODE-toewijzing kent (een niet-IBM databaseserver). U kunt de SQLCODE-toewijzing ook uitschakelen.
Zie SQLCODE-toewijzing voor meer informatie.
De systeemcatalogi verschillen per IBM-databaseproduct. Veel van deze verschillen kunnen teniet worden gedaan door middel van views. Raadpleeg de documentatie bij de door u gebruikte databaseserver voor meer informatie.
De catalogusfuncties in CLI omzeilen dit probleem door ondersteuning te bieden van dezelfde API en dezelfde resultaatsets voor catalogusquery's in alle DB2-producten.
Overloop van numerieke conversie bij ophaalbewerkingen kan op verschillende manieren worden verwerkt door verschillende relationele databaseproducten van IBM. Een voorbeeld hiervan is als een kolom met decimale getallen wordt opgehaald uit DB2 Universal Database for OS/390 en DB2 Universal Database en wordt omgezet in een hostvariabele met gehele getallen. Als een decimale waarde wordt geconverteerd naar een integerwaarde, treedt mogelijk een conversie-overloop op. DB2 Universal Database for OS/390 verzendt standaard een waarschuwings-SQLCODE en een nullwaarde naar de toepassing. DB2 Universal Database verstuurt echter een foutbericht over de conversie-overloop. Het is raadzaam toepassingen hostvariabelen met de juiste grootte op te laten halen om een overloop bij numerieke conversie te voorkomen.
DB2 Connect accepteert de volgende vergrendelingsniveaus wanneer u op de toepassing een PREP of BIND uitvoert:
De vergrendelingsniveaus zijn van boven naar beneden gerangschikt in volgorde van grootste beveiliging naar kleinste beveiliging. Als de host- of AS/400-server het door u opgegeven vergrendelingsniveau niet ondersteunt, wordt het volgende hoogst ondersteunde niveau gebruikt.
Tabel 2 toont het resultaat van elk vergrendelingsniveau op elke
host- of AS/400-toepassingenserver.
Tabel 2. Vergrendelingsniveaus
DB2 Connect | DB2 Universal Database for OS/390 | DB2 for VSE & VM | DB2 Universal Database for AS/400 | DB2 Universal Database |
---|---|---|---|---|
RR | RR | RR | Opmerking 1 | RR |
RS | Opmerking 2 | RR | COMMIT(*ALL) | RS |
CS | CS | CS | COMMIT(*CS) | CS |
UR | Opmerking 3 | CS | COMMIT(*CHG) | UR |
NC | Opmerking 4 | Opmerking 5 | COMMIT(*NONE) | UR |
Opmerkingen:
|
Met DB2 Universal Database for AS/400 kunt u toegang krijgen tot een niet in het journaal opgenomen tabel als er een bind is uitgevoerd van de toepassing met een vergrendelingsniveau van UR en als BLOCKING is ingesteld op ALL, of als het vergrendelingsniveau is ingesteld op NC.
Een clientprogramma kan een serverprogramma oproepen door de SQL-instructie CALL op te geven. Elke server werkt hierbij op een iets andere manier dan andere servers.
Alle CALL-instructies aan DB2 for AS/400 vanaf REXX/SQL, moeten dynamisch worden voorbewerkt en uitgevoerd door de toepassing, omdat een CALL-instructie die is geïmplementeerd in REXX/SQL wordt omgezet in CALL USING DESCRIPTOR.
Raadpleeg SQL Reference voor de syntaxis van de SQL-instructie CALL. Raadpleeg de Application Development Guide voor informatie over het gebruik van opgeslagen procedures bij het schrijven van toepassingsprogramma's.
U kunt het serverprogramma oproepen op DB2 Universal Database met dezelfde parameterconventie als die door de serverprogramma's wordt gebruikt op DB2 Universal Database for OS/390, DB2 Universal Database for AS/400 of DB2 for VSE & VM. Raadpleeg de Application Development Guide voor meer informatie over het oproepen van de opgeslagen procedures van DB2 Universal Database. Raadpleeg de DB2-productinformatie over het betreffende platform, voor meer informatie over de parameterconventie op andere platforms.
Alle SQL-instructies in een opgeslagen procedure worden uitgevoerd als onderdeel van een SQL-werkeenheid die is gestart door het SQL-clientprogramma.
Tussen de DB2 Universal Database-systemen onderling wordt alles doorgegeven wat u in de indicatorvariabelen plaatst. Als echter DB2 Connect wordt gebruikt, kunt u alleen de waarden 0, -1 en -128 in de indicatorvariabelen doorgeven.
Met een serverprogramma op DB2 Universal Database kan de SQLCA worden bijgewerkt voor het terugzenden van een foutbericht of een waarschuwing, maar een opgeslagen procedure op DB2 Universal Database for OS/390 of DB2 Universal Database for AS/400 heeft die ondersteuning niet. Als u een foutcode wilt terugzenden vanaf een opgeslagen procedure, moet u deze doorgeven als parameter. SQLCODE en SQLCA zijn alleen ingesteld door de server voor fouten die door het systeem zijn vastgesteld.
DB2 Stored Procedure Builder biedt een gebruiksvriendelijke ontwikkelingsomgeving voor het maken, installeren en testen van opgeslagen procedures. Hiermee kunt u zich concentreren op de ontwikkeling van de logica achter opgeslagen procedures en hoeft u zich niet bezig te houden met de details van het registreren, opbouwen en installeren van opgeslagen procedures op een DB2-server. Bovendien kunt u met Stored Procedure Builder opgeslagen procedures ontwikkelen op het ene besturingssysteem en vervolgens opbouwen op een ander serverbesturingssysteem.
Stored Procedure Builder is een grafische toepassing met ondersteuning voor versnelde ontwikkeling. Met Stored Procedure Builder kunt u de volgende taken uitvoeren:
U kunt Stored Procedure Builder starten als afzonderlijke toepassing vanuit de programmagroep DB2 Universal Database of u kunt Stored Procedure Builder starten via een van de volgende ontwikkelingstoepassingen:
U kunt Stored Procedure Builder ook starten vanuit het Besturingscentrum voor DB2 for OS/390. Hier kunt u Stored Procedure Builder starten als afzonderlijk proces via het menu Extra, de werkbalk of de map Stored Procedures van het Besturingscentrum. Daarnaast kunt u in het venster Project van Stored Procedure Builder een of meer geselecteerde opgeslagen SQL-procedures die zijn gemaakt op een DB2 for OS/390-server exporteren naar een opgegeven bestand dat via de Opdrachtregelinterface (CLP) kan worden uitgevoerd.
Uw werk wordt in Stored Procedure Builder beheerd met behulp van projecten. In elk project van Stored Procedure Builder worden de verbindingen met bepaalde databases opgeslagen, zoals DB2 for OS/390-servers. U kunt ook filters maken om subsets van de opgeslagen procedures in elke database af te beelden. Als u een nieuw of bestaand project van Stored Procedure Builder opent, kunt u de opgeslagen procedures filteren en afbeelden op basis van naam, schema, taal of collection-ID (alleen voor OS/390).
De verbindingsgegevens worden opgeslagen in een project van Stored Procedure Builder. Als u dus een bestaand project opent, wordt u automatisch gevraagd uw gebruikers-ID en wachtwoord voor de database in te voeren. Met de wizard Inserting SQL Stored Procedure kunt u opgeslagen SQL-procedures opbouwen op een DB2 for OS/390-server. Voor een opgeslagen SQL-procedure die is gemaakt voor een DB2 for OS/390-server kunt u bepaalde compileer-, pre-link-, link-, bind-, uitvoerings-, omgevings- en externe-beveiligingsopties instellen.
U kunt ook SQL-kostprijsgegevens over de opgeslagen SQL-procedure opvragen, zoals gegevens over de CPU-tijd, en andere DB2-kostprijsgegevens voor de thread waarop de opgeslagen SQL-procedure wordt uitgevoerd. U kunt met name kostprijsgegevens opvragen over de wachttijd bij vergrendelingsrivaliteit, het aantal opgehaalde pagina's, het aantal leesbewerkingen en het aantal schrijfbewerkingen.
Als u kostprijsgegevens opvraagt, wordt met Stored Procedure Builder een verbinding gemaakt met een DB2 for OS/390-server, wordt de SQL-instructie uitgevoerd en wordt een opgeslagen procedure (DSNWSPM) aangeroepen om te controleren hoeveel CPU-tijd de opgeslagen SQL-procedure heeft gebruikt.
Samengestelde SQL biedt de mogelijkheid meerdere SQL-instructies samen te voegen tot een uitvoerbaar blok. Mogelijk wordt hierdoor de netwerkoverhead verminderd en de responstijd verbeterd.
DB2 Connect ondersteunt samengestelde SQL-instructies van het type NOT ATOMIC. Dit betekent dat het verwerken van een samengestelde SQL-instructie wordt voortgezet na een foutbericht. (Bij samengestelde SQL-instructies van het type ATOMIC, welk type niet wordt ondersteund door DB2 Connect, wordt na een fout een ROLLBACK uitgevoerd op de hele groep van samengestelde SQL-instructies.)
De uitvoering van de instructies zal worden voortgezet, totdat deze wordt beëindigd door de toepassingenserver. In het algemeen wordt de uitvoering van samengestelde SQL-instructies alleen beëindigd in het geval van ernstige fouten.
Samengestelde SQL van het type NOT ATOMIC kan worden gebruikt met alle ondersteunde host- of AS/400-toepassingenservers.
Als er meerdere SQL-fouten optreden, worden de SQLSTATE's van de eerste zeven mislukte instructies teruggezonden in het SQLERRMC-veld van de SQLCA met het bericht dat er meerdere fouten zijn opgetreden. Raadpleeg SQL Reference voor meer informatie hierover.
DB2 Connect biedt u de mogelijkheid een update op meerdere locaties uit te voeren, die ook COMMIT in twee fasen wordt genoemd. Een update op meerdere locaties staat tevens bekend als update op meerdere databases binnen één gedistribueerde werkeenheid (DUOW). Of u kunt gebruikmaken van deze mogelijkheid, hangt af van verschillende factoren:
Het bovenstaande geldt voor oorspronkelijke DB2 UDB-toepassingen en toepassingen die worden bestuurd door een externe TP-monitor (Transaction Processor) zoals IBM TXSeries, CICS voor open systemen, BEA Tuxedo, Encina Monitor en Microsoft Transaction Server.
Opmerking: | Zie DB2 Connect en TP-monitors voor meer informatie over BEA Tuxedo.Zie DB2 Connect-verbindingsconcentrator voor meer informatie over de XA-concentrator. |
Als een gemeenschappelijke DB2 Connect Enterprise Edition-server zowel door oorspronkelijke DB2-toepassingen als door TP-monitortoepassingen wordt gebruikt voor toegang tot hostgegevens via TCP/IP-verbindingen, moet u gebruikmaken van Syncpointbeheer.
Als één DB2 Connect Enterprise Edition-server wordt gebruikt voor toegang tot hostgegevens via SNA- en TCP/IP-netwerkprotocollen en COMMIT in twee fasen is vereist, moet u eveneens gebruikmaken van Syncpointbeheer. Dit geldt voor DB2-toepassingen en TP-monitortoepassingen.
De volgende instructies compileren correct voor de verwerking door de host- of AS/400-server, maar niet voor de verwerking door DB2 Universal Database-systemen:
Deze instructies worden ook ondersteund door de opdrachtregelinterface.
De volgende instructies worden ondersteund voor de verwerking door host- of AS/400-servers, maar worden niet toegevoegd aan het bindbestand of aan het pakket en worden niet ondersteund door de opdrachtregelinterface:
De precompiler neemt het volgende aan:
De volgende SQL-instructies worden niet ondersteund door DB2 Connect of de opdrachtregelinterface:
Met DB2 for VSE & VM worden uitgebreide dynamische SQL-instructies afgewezen met SQLCODE -104 en SQLCODE's voor syntaxisfouten.