Wenn der Befehl export mit einem IXF-Dateiformat und der |Klausel SELECT * abgesetzt wird, werden ggf. Indexierungsinformationen erfasst.
|Wenn die im Index angegebenen Spaltennamen die Zeichen - oder + enthalten, werden die Indexierungsinformationen nicht erfasst, und Sie erhalten den SQL-Code SQL27984W. Der Export wird beendet, ohne dass sich dies auf die exportierten Daten auswirkt. |Die Indexierungsinformationen werden jedoch nicht in der IXF-Datei gespeichert.
Wenn Sie die Tabelle mit dem Befehl import und dem Parameter CREATE erneut erstellen, werden die Indizes nicht erneut erstellt. |Die Indizes können Sie mit dem Dienstprogramm db2look separat erstellen.
Wenn Sie die API db2ReadLog über eine Anwendung aufrufen, kann dies beim Trennen der Anwendung von der Datenbank einen Fehler verursachen, falls zuvor keine COMMIT- oder ROLLBACK-Operation ausgeführt wird:
|Schalten Sie für nicht eingebettete SQL-Anwendungen den Modus für automatisches Festschreiben ein, bevor Sie die API db2ReadLog aufrufen.
Setzen Sie nach dem Aufruf der API db2ReadLog eine COMMIT- oder ROLLBACK-Anweisung ab, bevor Sie die Verbindung zur Datenbank trennen.
Der Befehl 'db2gcf' startet, stoppt oder überwacht ein DB2 Universal Database-Exemplar in der Regel in einer automatisierten Prozedur, wie z. B. in einem Cluster mit hoher Verfügbarkeit.
Die Verwendung des Systembefehls 'db2gcf' mit dem Parameter -k unter DB2 UDB Workgroup Server schlägt fehl.
Der Befehl "db2gcf -k" kann nur unter DB2 UDB Enterprise Server Edition, nicht jedoch unter DB2 UDB Workgroup Server Edition eingesetzt werden.
Wenn ein 32-Bit-DB2 Universal Database-Server auf einem AIX-System ausgeführt wird und eine Anwendung, die auf demselben System aktiv ist, mehrere Daten- bankverbindungen über den DRDA-Wrapper aufweist, empfängt die Anwendung möglicherweise den folgenden Fehler:
SQL1822N Es wurde ein unerwarteter Fehlercode "-1224"
von der Datenquelle "W3_SERVER2" empfangen.
Zugeordneter Text und Token sind
func="DriverConnect"
msg="SQL1224N Ein Datenbankagent konnte nicht für die Anforderung
gestartet werden, oder er wurde auf Grund eines
Systemabschlusses der Datenbank bzw. durch den Befehl
FORCE beendet."
SQLSTATE=560BD
Sie vermeiden diesen Fehler, indem Sie in die Konfigurationsdatei für zusammengeschlossene Datenbanken (exemplarverzeichnis/cfg/db2dj.ini) den folgenden Eintrag einfügen:
EXTSHM=ON
Sie können jedoch auch die lokale DB2 UDB-Datenbank so katalogisieren, dass sie sich auf einem TCP/IP-Knoten befindet. Beispiel:
CATALOG TCPIP NODE mein_knoten REMOTE mein_host SERVER 123; CATALOG DB meinedb AT NODE mein_knoten; CREATE WRAPPER drda; CREATE SERVER mein_server TYPE DB2/UDB VERSION 8 WRAPPER drda AUTHORIZATION "meine_id" PASSWORD "mein_kennwort" OPTIONS(ADD DBNAME 'MEINEDB');
Wenn Ihre Direktaufrufe in Microsoft Visual Studio .NET Framework 1.1 nicht funktionieren, können Sie von der Website von Microsoft ein Hotfix herunterladen. Sie finden das Hotfix in der Microsoft Knowledge Base unter Artikel Q836745.
Unter AIX wurde der codierte Zeichensatz für die Ländereinstellung für vereinfachtes Chinesisch Zh_CN für folgende Versionen geändert:
Der Zeichensatz wurde von GBK (Codepage 1386) in GB18030 (Codepage 5488 oder 1392) geändert. Da DB2 Universal Database (UDB) für AIX den Zeichensatz GBK nativ und den Zeichensatz GB18030 über Unicode unterstützt, legt DB2 UDB den codierten Zeichensatz der Ländereinstellung Zh_CN standardmäßig auf ISO 8859-1 (Codepage 819) fest. Darüber hinaus wird bei einigen Operationen als Gebiet der Ländereinstellung die USA (US) festgelegt.
Es gibt zwei Möglichkeiten, um diese Einschränkung zu umgehen:
Wenn Sie sich für die erste Möglichkeit entscheiden, setzen Sie die folgenden Befehle ab:
db2set DB2CODEPAGE=1386 db2set DB2TERRITORY=86 db2 terminate db2stop db2start
Wenn Sie sich für die zweite Möglichkeit entscheiden, ändern Sie die Ländereinstellung von Zh_CN in ZH_CN oder zh_CN. Der codierte Zeichensatz der Ländereinstellung ZH_CN ist Unicode (UTF-8), der codierte Zeichensatz der Ländereinstellung zh_CN ist eucCN (Codepage 1383).
In Red Hat Version 8 oder höher (einschließlich Red Hat Enterprise Linux [RHEL] Version 2.1 und Version 3) wurde der Standardwert für den codierten Zeichensatz für vereinfachtes Chinesisch von GBK (Codepage 1386) in GB18030 (Codepage 5488 oder 1392) geändert.
Da DB2 Universal Database (UDB) für Linux den Zeichensatz GBK nativ und den Zeichensatz GB18030 über Unicode unterstützt, legt DB2 UDB seinen codierten Zeichensatz standardmäßig auf ISO 8859-1 (Codepage 819) fest. Darüber hinaus wird bei einigen Operationen als Gebiet die USA (US) festgelegt.
Es gibt zwei Möglichkeiten, um diese Einschränkung zu umgehen:
Wenn Sie sich für die erste Möglichkeit entscheiden, setzen Sie die folgenden Befehle ab:
db2set DB2CODEPAGE=1386 db2set DB2TERRITORY=86 db2 terminate db2stop db2start
Wenn Sie sich für die zweite Möglichkeit entscheiden, setzen Sie einen der folgenden Befehle ab:
export LANG=zh_CN.gbk export LANG=zh_CN export LANG=zh_CN.utf8
Dabei ist der codierte Zeichensatz, der zh_CN zugeordnet ist, eucCN oder Codepage 138, und der codierte Zeichensatz, der zh_CN.utf8 zugeordnet ist, Codepage 1208.
Bei der Unicode-Unterstützung sind Inkompatibilitäten vorhanden, wenn Merant Driver Manager unter UNIX auf den ODBC-Treiber von DB2 zugreift. Auf Grund dieser Inkompatibilitäten wird Merant Driver Manager zur Verwendung von Unicode veranlasst, selbst wenn die Anwendung die Unicode-Verwendung nicht angefordert hat. Dies kann zu Problemen mit Komponenten wie der Data Warehouse-Zentrale, Information Catalog Manager und MQSI führen, die Merant Driver Manager zur Unterstützung von Nicht-IBM Datenquellen benötigen. Sie können eine alternative DB2-ODBC-Treiberbibliothek ohne aktivierte Unicode-Unterstützung verwenden, bis eine dauerhafte Lösung zur Verfügung steht.
Eine alternative DB2-ODBC-Treiberbibliothek ohne aktivierte Unicode-Unterstützung ist in DB2 Universal Database (UDB) Version 8.1 für AIX, HP-UX und die Solaris-Betriebsumgebung enthalten. Zur Verwendung der alternativen Bibliothek müssen Sie eine Kopie von dieser erstellen und die Kopie mit dem Originalnamen der DB2-ODBC-Treiberbibliothek benennen.
Beachten Sie folgende Hinweise, um zur Nicht-Unicode-ODBC-Bibliothek unter AIX, HP-UX oder der Solaris-Betriebsumgebung umschalten zu können: Da es sich dabei um einen manuellen Prozess handelt, müssen Sie diesen bei jeder Aktualisierung Ihres Produkts ausführen, ebenso nach Anwendung nachfolgender FixPaks oder Modifikationsstufen.
Gehen Sie wie folgt vor, um die alternative Bibliothek unter AIX zu erstellen:
cp db2_36.o db2.o -r--r--r-- bin:bin for db2.o
Um wieder zum Originalobjekt zu wechseln, führen Sie dieselbe Prozedur aus. Verwenden Sie dabei die Sicherungsdatei an Stelle der Datei db2_36.o.
Gehen Sie wie folgt vor, um die alternative Bibliothek in einer Solaris-Betriebsumgebung zu erstellen:
cp libdb2_36.so.1 libdb2.so.1 -r-xr-xr-x bin:bin libdb2.so.1
Um wieder zum Originalobjekt zu wechseln, führen Sie dieselbe Prozedur aus. Verwenden Sie dabei die Sicherungsdatei an Stelle der Datei libdb2_36.so.1.
Gehen Sie wie folgt vor, um die alternative Bibliothek unter HP-UX PA-RISC zu erstellen:
cp libdb2_36.sl libdb2.sl -r-xr-xr-x bin:bin for libdb2.sl
Um wieder zum Originalobjekt zu wechseln, führen Sie dieselbe Prozedur aus. Verwenden Sie dabei die Sicherungsdatei an Stelle der Datei libdb2_36.sl.
Gehen Sie wie folgt vor, um die alternative Bibliothek unter HP-UX auf IA64-Plattformen zu erstellen:
cp libdb2_36.so libdb2.so -r-xr-xr-x bin:bin for libdb2.so
Um wieder zum Originalobjekt zu wechseln, führen Sie dieselbe Prozedur aus. Verwenden Sie dabei die Sicherungsdatei an Stelle der Datei libdb2_36.so.
Wenn Sie Unterstützung für DB2 UDB und Merant Driver Manager auf anderen UNIX-Betriebssystemen benötigen, wenden Sie sich bitte an die IBM Unterstützungsfunktion.
NFS-APAR IY32512 für AIX 5 kann bewirken, dass der Befehl db2stop auf Systemen mit einer großen Partitionsanzahl fehlschlägt.
Auf einem Server, der viele Anforderungen für Blocksperren für Dateien empfängt, die bereits gesperrt sind, antwortet der Sperrdämon möglicherweise nicht mehr. Dies tritt auf, wenn alle verfügbaren gesperrten Threads den Threads zugeordnet werden, die darauf warten, dass Sperren verfügbar werden, so dass kein Thread verfügbar ist, um die Arbeit wiederaufzunehmen, wenn die Entsperranforderung erfolgt.
In dieser Situation müssen die gestoppten Knoten erneut gestartet werden. Es gibt in dieser Situation eine Fehlerumgehung für DB2 Universal Database: Sie stoppen die Knoten jeweils einzeln, indem Sie die Option NODENUM des Befehls db2stop verwenden.
Wenn die Precompileroption SQLFLAG(STD) aktiviert ist, wird ein Fehler angezeigt, dass es bei der Ausführung des Precompilerprogramms DSNHPC zu einer abnormalen Beendigung C6 kam.
Entfernen Sie die Precompileroption SQLFLAG(STD), wenn Sie die Entwicklungszentrale zum Erstellen gespeicherter SQL-Prozeduren verwenden, die unter DB2 Universal Database für z/OS Version 8 ausgeführt werden.
| | |DB2 Connect(TM) leitet Verbindungen zu anderen Elementen einer Distributed |Data Facility (DDF) nicht weiter, wenn das die Verbindung herstellende Element der DDF in einer Gruppe mit gemeinsamer Datennutzung für OS390 beendet wurde. Wenn Sysplex aktiviert ist, leitet DB2 Connect Verbindungen zu einem anderen Element in der DDF gemäß der Serverliste weiter.
|Sysplex für DB2 Connect Version 8 wurde unter Berücksichtigung der Verwendung von Agentenpools entworfen. |Die Sysplex-Serverliste wird freigegeben, falls für eine Datenbank keine Agenten und keine Verbindungen vorhanden sind. Daher muss mindestens ein Agent beibehalten werden, wenn die Sysplex-Serverliste beibehalten werden soll.
Aktivieren Sie das Verbindungspooling mit den folgenden Befehlen:
|db2 update dbm cfg using num_poolagents anzahl |db2stop |db2start
Dabei steht anzahl für die maximale Anzahl Agenten, die für Pools des DB2-Exemplars zugelassen sind. Das Verbindungspooling ist aktiviert, wenn anzahl größer als null ist.
|Setzen Sie num_poolagents auf -1, was der Hälfte des Werts entspricht, auf den der Konfigurationsparameter maxagents gesetzt ist.
Obwohl DB2 Connect Custom Advisor im DB2 Connect Benutzerhandbuch dokumentiert ist, wird er in Version 8.2 nicht mehr unterstützt.
Dieser Fehler kann auch auftreten, wenn Sie DB2 UDB Version 8.1 FixPak 7 installieren, falls Sie den Konfigurationsparameter jdk_path des DB2-Verwaltungsservers manuell so aktualisiert haben, dass er auf HP-UX SDK 1.4 zeigt, oder falls Sie den DB2-Verwaltungsserver (DVS) gelöscht und erneut erstellt haben. Der Fehler tritt auf, da Sie in beiden Fällen den Konfigurationsparameter jdk_path so geändert haben, dass er auf HP-UX SDK 1.4 zeigt.
Ein 32-Bit-Exemplar von DB2 UDB Version 8.2 erfordert HP-UX SDK 1.3, um erfolgreich ausgeführt zu werden.
db2 update admin config using JDK_PATH /opt/java1.3
db2admin stop db2admin start
Wenn Sie bei der Verwendung der GUI-Tools von DB2 Probleme mit der Anzeige von indischen Schriftzeichen haben, haben Sie die erforderlichen Schriftarten möglicherweise nicht auf Ihrem System installiert.
DB2 Universal Database (UDB) wird mit den folgenden proportionalen IBM TrueType- und OpenType-Schriftarten für indische Sprachen geliefert. Sie können diese Schriftarten im Verzeichnis font auf einer der folgenden CDs finden:
Diese Schriftarten sind nur für die Verwendung mit DB2 UDB bestimmt. Diese Schriftarten dürfen weder im allgemeinen noch im uneingeschränkten Verkauf noch zur Verteilung angeboten werden:
| Schriftbild | Schriftstärke | Name der Schriftartdatei |
|---|---|---|
| Devanagari MT für IBM | Mittel | devamt.ttf |
| Devanagari MT für IBM | Fett | devamtb.ttf |
| Tamil | Mittel | TamilMT.ttf |
| Tamil | Fett | TamilMTB.ttf |
| Telugu | Mittel | TeluguMT.ttf |
| Telugu | Fett | TeleguMTB.ttf |
Genaue Anweisungen zur Installation der Schriftarten und zur Modifizierung der Datei font.properties finden Sie im Abschnitt zur Internationalisierung in der Dokumentation zu IBM Development Kit für Java.
Darüber hinaus werden die folgenden Produkte von Microsoft mit Schriftarten für indische Sprachen geliefert. Sie können ebenfalls mit den GUI-Tools von DB2 verwendet werden:
Mit Ausnahme des DB2-Installationsassistenten funktionieren die GUI-Tools auf zSeries-Servern mit Linux-Betriebssystem nicht. Diese Einschränkung umfasst alle Elemente, die normalerweise über die Klickstartleiste für die Installation gestartet werden, wie beispielsweise der Kurzüberblick.
Wenn Sie die GUI-Tools mit einem dieser Systeme verwenden möchten, instal- lieren Sie die Verwaltungstools auf einem Clientsystem mit einer anderen Systemkonfiguration, und verwenden Sie diesen Client, um eine Verbindung zu Ihrem zSeries-Server herzustellen.
Wenn Sie in 'DB2 Information - Unterstützung' genaue Suchergebnisse erhalten möchten, müssen Sie Suchbegriffe, die Ziffern enthalten, in Anführungszeichen einschließen.
Wenn Sie z. B. nach dem folgenden Begriff suchen, erhalten Sie keine Ergebnisse:
1.4.1
Wenn Sie jedoch diesen Suchbegriff in Anführungszeichen einschließen, erhalten Sie die entsprechenden Ergebnisse:
"1.4.1"
Eine Suche nach dem folgenden Suchbegriff gibt mehr Themen als erwartet zurück:
DB20000I
Eine Suche nach dem folgenden Begriff funktioniert jedoch wie erwartet:
"DB20000I"
Wenn die Protokolldatei der Informationskatalogzentrale beim Importieren von Befehlssprachendateien in die Informationskatalogzentrale nicht generiert wird, führen Sie folgende Schritte zur Fehlerbehebung durch:
db2javit -j:com.ibm.db2.common.icm.tag.IcmImport -w: -i: -o:"-Xmx128m -Xms32m" -g:"d:\temp\myimport.trc" ...
Wenn die Query Patroller-Pakete nach Anwendung eines FixPaks nicht gebunden werden, besteht die Möglichkeit, dass ein Benutzer ohne Datenbankadministratorberechtigung oder entsprechende Query Patroller-Zugriffsrechte bei Verwendung der Query Patroller-Zentrale oder der Query Patroller-Befehlszeile den folgenden Fehler empfängt:
SQL0001N - Binden oder Vorkompilieren nicht erfolgreich abgeschlossen.
Wenn Sie mit der Query Patroller-Zentrale arbeiten, wird der Fehler SQL0001N in der Datei qpdiag.log protokolliert. Wenn Sie mit der Query Patroller-Befehlszeile arbeiten, wird SQL0001N an die Konsole zurückgegeben.
Zum Einleiten einer automatischen Bindung steht ein entsprechender Code zur Verfügung. Die automatische Bindung schlägt jedoch fehl, wenn der Benutzer, der die Verbindung herstellt, nicht über die erforderlichen Zugriffsrechte zur Ausführung aller Anweisungen in den Query Patroller-Paketen verfügt. Eine Folge dieses Fehlers ist, dass in der Query Patroller-Zentrale Ordner fehlen.
Zur Vermeidung dieses Fehlers sollten die qpserver.lst-Pakete nach Anwendung eines FixPaks von einem Benutzer mit DBADM-Berechtigung oder entsprechenden Zugriffsrechten manuell gebunden werden.
Übergebene Abfragen in Query Patroller empfangen möglicherweise den SQL-Code -29007, wenn unter Windows XP oder Windows 2003 keine Ports mehr verfügbar sind. Die Wahrscheinlichkeit dieses Fehlers nimmt zu, wenn die Anzahl der Clients zunimmt, die auf Query Patroller zugreifen.
Setzen Sie die folgenden Windows-Registrierdatenbankvariablen:
MaxUserPort=65534 TcpTimedWaitDelay=30
Starten Sie anschließend das System erneut, damit die Änderungen wirksam werden.
Details zum Setzen von Windows-Registrierdatenbankvariablen finden Sie unter der URL-Adresse http://support.microsoft.com/ auf der Microsoft(R)-Website für Hilfe und Unterstützung.
Wenn Sie DB2 Universal Database (UDB) unter Windows verwenden und für das Windows-System keine Administratorrechte haben, können Dateiberechtigungsprobleme auftreten. Wenn Sie die Fehlernachricht SQL1035N, SQL1652N oder SQL5005C empfangen, sind folgende Ursachen und Fehlerumgehungen möglich:
Erteilen Sie den Benutzern mindestens die Berechtigung zum Modifizieren (MODIFY) für das Verzeichnis exemplarverzeichnis auf Dateisystemebene.
Die Namen einiger XML Extender-Beispielprogramme sind möglicherweise mit den Namen anderer installierter Programme identisch. Wenn versehentlich ein anderes Programm mit demselben Namen wie das XML Extender-Beispielprogramm aufgerufen wird, können Ihre XML-Dateien beschädigt werden. In der folgenden Liste sind die alten Namen der XML Extender-Beispielprogramme sowie neue Pro- grammnamen aufgeführt, die seltener Konflikte verursachen. Verwenden Sie an Stelle der alten Namen unbedingt die neuen Namen für die Beispielprogramme, damit keine XML-Dateien beschädigt werden.
| Altes Programm (Nicht mehr verwenden) | Neues Programm (Verwenden) |
|---|---|
| insertx.exe | dxxisrt.exe |
| retrieve.exe | dxxretr.exe |
| retrieve2.exe | dxxretr2.exe |
| retrievec.exe | dxxretrc.exe |
| shred.exe | dxxshrd.exe |
| tests2x.exe | dxxgenx.exe |
| tests2xb.exe | dxxgenxb.exe |
| tests2xc.exe | dxxgenxc.exe |
| Altes Programm (Nicht mehr verwenden) | Neues Programm (Verwenden) |
|---|---|
| insertx | dxxisrt |
| retrieve | dxxretr |
| retrieve2 | dxxretr2 |
| retrievec | dxxretrc |
| shred | dxxshrd |
| tests2x | dxxgenx |
| tests2xb | dxxgenxb |
| tests2xc | dxxgenxc |
Der Quellcode (sqx-Dateien) für die oben aufgeführten ausführbaren Dateien befindet sich im Verzeichnis samples\db2xml\c Ihrer Installation. Die Quellendateien werden immer noch mit ihren alten Namen bezeichnet. Wenn Sie Änderungen am Quellcode vornehmen, kopieren Sie Ihre neu kompilierten ausführbaren Dateien (mit den alten Namen) in das Verzeichnis sqllib\bin.
Auf Windows-Plattformen müssen Sie eine zusätzliche Kopie erstellen, diese mit ihrem oben aufgeführten, neuen Namen benennen und in das Verzeichnis bin kopieren. Beide Kopien ersetzen die im bin-Verzeichnis vorhandenen Dateien. Nach dem Kompilieren Ihrer neuen Version von shred.exe müssen Sie zum Beispiel zwei Kopien machen und die Dateien im bin-Verzeichnis ersetzen: eine Datei shred.exe und die andere umbenannte Datei dxxshrd.exe.
Auf Linux- und UNIX-Plattformen müssen Sie nur die Datei mit dem alten Namen durch Ihre neu kompilierte Version ersetzen. Wenn Sie anhand dieser Programme neue ausführbare Dateien erstellen, müssen Sie die neuen Dateien aus dem Verzeichnis \SQLLIB\samples\db2xml\c\ in das Verzeichnis \SQLLIB\bin\ kopieren. Erstellen Sie dann eine zusätzliche Kopie, indem Sie die Dateien gemäß der obigen Tabelle umbenennen.
Sie können jetzt Dokumente zerlegen, die nicht eindeutige Attribute oder Elementnamen enthalten, die verschiedenen Spalten (der gleichen oder verschiedener Tabellen) zugeordnet sind, ohne die Fehlermeldung DXXQ045E zu erhalten. Es folgt ein ein Beispiel eines XML-Dokuments mit nicht eindeutigen Attributen und nicht eindeutigen Elementnamen:
<Order ID="0001-6789">
<!-- Anmerkung: Die Attributnamen-ID ist nicht eindeutig -->
<Customer ID = "1111">
<Name>John Smith</Name>
</Customer>
<!-- Anmerkung: Der Elementname 'Name' ist nicht eindeutig -->
<Salesperson ID = "1234">
<Name>Jane Doe</Name>
</Salesperson>
<OrderDetail>
<ItemNo>xxxx-xxxx</ItemNo>
<Quantity>2</Quantity>
<UnitPrice>12.50</UnitPrice>
</OrderDetail>
<OrderDetail>
<ItemNo>yyyy-yyyy</ItemNo>
<Quantity>4</Quantity>
<UnitPrice>24.99</UnitPrice>
</OrderDetail>
</Order>Die zugehörige DAD, welche die kopierten Elemente und Attribute anderen Spalten zuordnet, sieht wie folgt aus:
<element_node name="Order">
<RDB_node>
<table name="order_tab" key="order_id"/>
<table name="detail_tab"/>
<condition>
order_tab.order_id=detail_tab.order_id
</condition>
</RDB_node>
<!-- Attribut-ID unten kopiert, aber einer anderen Spalte zugeordnet -->
<attribute_node name="ID">
<RDB_node>
<table name="order_tab" />
<column name="order_id" type="char(9)"/>
</RDB_node>
</attribute_node>
<element_node name="Customer">
<!-- Attribut-ID oben kopiert, aber einer anderen Spalte zugeordnet -->
<attribute_node name="ID">
<RDB_node>
<table name="order_tab" />
<column name="cust_id" type="integer"/>
</RDB_node>
</attribute_node>
<!-- Elementname unten kopiert, aber einer anderen Spalte zugeordnet -->
<element_node name="Name">
<text_node>
<RDB_node>
<table name="order_tab" />
<column name="cust_name" type="char(20)" />
</RDB_node>
</text_node>
</element_node>
</element_node>
<element_node name="Salesperson">
<!-- Attribut-ID oben kopiert, aber einer anderen Spalte zugeordnet -->
<attribute_node name="ID">
<RDB_node>
<table name="order_tab" />
<column name="salesp_id" type="integer"/>
</RDB_node>
</attribute_node>
<!-- Elementname oben kopiert, aber einer anderen Spalte zugeordnet -->
<element_node name="Name">
<text_node>
<RDB_node>
<table name="order_tab" />
<column name="salesp_name" type="char(20)" />
</RDB_node>
</text_node>
</element_node>
</element_node>
<element_node name="OrderDetail" multi_occurrence="YES">
<element_node name="ItemNo">
<text_node>
<RDB_node>
<table name="detail_tab" />
<column name="itemno" type="char(9)"/>
</RDB_node>
</text_node>
</element_node>
<element_node name="Quantity">
<text_node>
<RDB_node>
<table name="detail_tab" />
<column name="quantity" type="integer"/>
</RDB_node>
</text_node>
</element_node>
<element_node name="UnitPrice">
<text_node>
<RDB_node>detail_tab" />
<table name="detail_tab" />
<column name="unit_price" type="decimal(7,2)"/>
</RDB_node>
</text_node>
</element_node>
</element_node>
</element_node>Der Inhalt der Tabellen würde nach dem Zerlegen des vorangegangenen Dokuments wie folgt aussehen:
ORDER _TAB: ORDER_ID CUST_ID CUST_NAME SALESP_ID SALESP_NAME 0001-6789 1111 John Smith 1234 Jane Doe DETAIL_TAB: ORDER_ID ITEMNO QUANTITY UNIT_PRICE 0001-6789 xxxx-xxxx 2 12.50 0001-6789 yyyy-yyyy 4 24.99
Bei der Herstellung einer Verbindung zu einem OS/390-System über SNA führt die VTAM-Schicht bei einer neuen Verbindung automatisch eine COMMIT-Operation aus. Die automatische COMMIT-Operation lässt zu, dass der Threadstatus des Hosts inaktiv ist. Deshalb wird der Thread sofort inaktiviert.
Bei der Herstellung einer Verbindung zu einem OS/390-System über TCP/IP gibt es jedoch keine automatische COMMIT-Operation. Die Anwendung selbst muss nach Herstellung der Verbindung eine explizite COMMIT-Operation ausführen, damit der Thread auf dem Host inaktiviert werden kann. Ohne die explizite COMMIT-Operation unterliegt der Thread einem Zeitlimit für ruhende Threads.
Zur Umgehung dieses Problems wird empfohlen, die Anwendung so umzuschreiben, dass eine explizite COMMIT-Operation ausgeführt wird, wenn die Verbindung nach deren Herstellung inaktiviert wird.
[ Seitenanfang |Vorherige Seite | Nächste Seite | Inhaltsverzeichnis ]