DB2 Connect Benutzerhandbuch


Dienstprogramm für die Ablaufverfolgung (ddcstrc)

Das Dienstprogramm ddcstrc ermöglicht ein Aufzeichnen der Daten, die zwischen der DB2 Connect-Workstation (für den Datenbank-Client) und dem Verwaltungssystem des Datenbank-Servers auf dem Host oder System IBM AS/400 ausgetauscht werden.

Die Kenntnis dieses Datenstroms ist für den Datenbankadministrator und den Anwendungsentwickler oft sehr hilfreich, da anhand dieses Wissens die Ursachen bestimmter Fehler gefunden werden können. Beispielsweise könnte eine Anweisung CONNECT TO für eine Datenbank eines Datenbank-Servers auf dem Host oder System IBM AS/400 abgesetzt werden und infolge des Fehlschlagens des Befehls ein Rückkehrcode empfangen werden, der auf einen Fehler hinweist. Wenn genau bekannt ist, welche Informationen an das Verwaltungssystem des Datenbank-Servers auf dem Host oder System IBM AS/400 übertragen wurden, kann die Fehlerursache auch dann ermittelt werden, wenn die Informationen des Rückkehrcodes allgemein sind. Häufig schlägt ein Befehl aufgrund eines einfachen Benutzerfehlers fehl.

In der Ausgabe von ddcstrc werden die zwischen der DB2 Connect-Workstation und dem Verwaltungssystem des Datenbank-Servers auf dem Host oder System IBM AS/400 ausgetauschten Datenströme aufgelistet. An den Host- oder AS/400-Datenbank-Server übertragene Daten werden unter SEND BUFFER (Sendepuffer), vom Host- oder AS/400-Datenbank-Server empfangene Daten unter RECEIVE BUFFER (Empfangspuffer) aufgeführt.

Wenn ein Empfangspuffer Informationen zum SQL-Kommunikationsbereich enthält, folgt auf diese eine formatierte Interpretation dieser Daten unter der Bezeichnung SQLCA. Das SQLCODE-Feld eines SQL-Kommunikationsbereichs ist der nicht zugeordnete Wert, so wie er vom Host- oder AS/400-Datenbank-Server geliefert wurde. Weitere Informationen zum Zuordnen finden Sie in Kapitel 11, SQLCODE-Zuordnung. Die Sende- und Empfangspuffer sind von den ältesten zu den neuesten innerhalb der Datei sortiert. Jeder Puffer verfügt über folgende Angaben:

Die weiteren Daten in Sende- und Empfangspuffern werden in den folgenden fünf Spalten dargestellt:

Die folgenden Handbücher enthalten weitere Informationen zu DDM:

Syntax des Befehls zur Ablaufverfolgung

Dieser Befehl wird von der Eingabeaufforderung des Betriebssystems aus mit folgender Syntax aufgerufen:

Abbildung 9. Syntax des Befehls
ddcstrc

Figure 00003491 not displayed.

Anmerkung:Die Syntax dieses Befehls kann je nach verwendetem Betriebssystem leicht variieren. Z. B. kann / beim Betriebssystem OS/2 anstelle von - verwendet werden.

Ablaufverfolgungsparameter

on
Aktiviert den DB2 Connect-Trace für DRDA-Datenströme zum/vom Host- oder AS/400-Datenbank-Server.

off
Inaktiviert den DB2 Connect-Trace für DRDA-Datenströme zum/vom Host- oder AS/400-Datenbank-Server.

-i
In die Ablaufverfolgungsinformation werden Zeitmarken aufgenommen.

-r
Verfolgt den Ablauf der DRDA-Datenströme, die vom Server-System auf dem Host oder System IBM AS/400 empfangen werden.

-s
Verfolgt den Ablauf der DRDA-Datenströme, die zum Host- oder AS/400-Datenbank-Server gesendet werden.

-c
Verfolgt den Ablauf des SQL-Kommunikationsbereichs, der vom Host- oder AS/400-Datenbank-Server empfangen wird.

-r, -s und -c werden als Standardwerte verwendet.

-l=länge
Gibt die Größe des Puffers an, in dem die Ablaufverfolgungsinformationen gespeichert werden. Der Standardwert beträgt 1 MB, der Minimalwert 64 KB.

-t=ablaufverfolgungsdatei
Gibt die Zieladresse für die Ablaufverfolgung an; ablaufverfolgungsdatei kann der Name einer Datei oder einer Standardeinheit sein. Wenn ein Dateiname ohne vollständigen Pfad angegeben wird, wird der aktuelle Pfad für die fehlenden Teile angenommen. Als Standardwert für den Dateinamen wird ddcstrc.dmp verwendet.

-p=pid
Eine Ablaufverfolgung wird nur für diesen Prozeß durchgeführt. Wenn -p nicht angegeben ist, werden alle Prozesse für das Exemplar des Benutzers in die Ausgabedatei geschrieben.
Anmerkung:Für einen fernen Client kann die Prozeß-ID (PID) dem vom Datenbanksystemmonitor übergebenen Feld für die Agenten-ID entnommen werden.
Kapitel 8, Datenbanksystemmonitor enthält weitere Informationen.

Ablaufverfolgungsausgabe

Das Dienstprogramm 'ddcstrc' schreibt die folgenden Informationen in die Trace-Datei:

Anmerkungen:

  1. Der Wert Null für den Endecode zeigt an, daß der Befehl erfolgreich ausgeführt wurde. Ein Wert ungleich Null zeigt an, daß der Befehl nicht erfolgreich ausgeführt wurde.

  2. Die zurückgegebenen Felder hängen von der verwendeten API ab. Die SNA-API wird nur für 2PC-SPM-Verbindungen verwendet.

  3. Welche Felder zurückgegeben werden, hängt von der Plattform ab, auf der DB2 Connect ausgeführt wird. Es können daher für dieselbe API unterschiedliche Felder zurückgegeben werden.

  4. Wenn ddcstrc die Ausgabe in eine bereits existierende Datei leitet, wird die alte Datei gelöscht, wenn die Berechtigungen für die Datei dies zulassen.

Analysieren der Ablaufverfolgungsausgabe

Auf den nächsten Seiten wird ein Beispiel einer Ausgabe gezeigt, das einige DRDA-Datenströme darstellt, die zwischen DB2 Connect-Workstations und einem Host- oder AS/400-Datenbank-Server ausgetauscht werden. Vom Standpunkt des Benutzers wurde über den Befehlszeilenprozessor ein Befehl CONNECT TO für eine Datenbank abgesetzt.

Abbildung 10 verwendet DB2 Connect Enterprise Edition Version 7 und DB2 Universal Database für OS/390 Version 5.1 über eine APPC-Verbindung.

Abbildung 11 verwendet DB2 Connect Enterprise Edition Version 7 und DB2 Universal Database für OS/390 Version 5.1 über eine TCP/IP-Verbindung.

Abbildung 10. Beispiel einer Ablaufverfolgungsausgabe (APPC-Verbindung)

1       DB2 fnc_data      gateway_drda_ar      sqljcsend (1.35.10.80)
        pid 95212; tid 537115484; node 0; cpid 0; sec 0; nsec 0; tpoint 177
 
        SEND BUFFER:  EXCSAT RQSDSS         (ASCII)           (EBCDIC)
         0 1 2 3 4 5 6 7  8 9 A B C D E F   0123456789ABCDEF  0123456789ABCDEF
  0000  006AD04100010064 10410020115E8482   .j.A...d.A. .^..  .|}..........;db
  0010  F282974040404040 4040404040404040   ...@@@@@@@@@@@@@  2bp
  0020  4040F0F0F0F1F7F3 C5C3000C116DA685   @@...........m..    000173EC..._we
  0030  81A2859340400013 115AC4C2F240C396   ....@@...Z...@..  asel  ...]DB2 Co
  0040  95958583A340F54B F200141404140300   .....@.K........  nnect 5.2.......
  0050  0414440003240700 05240F0003000D11   ..D..$...$......  ................
  0060  47D8C4C2F261F6F0 F0F00085D0010002   G....a..........  .QDB2/6000.e}...
  0070  007F200100162110 E2C1D56DC6D9C1D5   .. ...!....m....  ."......SAN_FRAN
  0080  C3C9E2C3D6404040 40400006210F2407   .....@@@@@..!.$.  CISCO     ......
  0090  000D002FD8E3C4E2 D8D3C1E2C3000C11   .../............  ....QTDSQLASC...
  00A0  2EE2D8D3F0F5F0F2 F0003C210437E2D8   ..........
3       DB2 fnc_data      gateway_drda_ar      sqljcsend (1.35.10.80)
        pid 95212; tid 537115484; node 0; cpid 0; sec 0; nsec 0; tpoint 177
 
        SEND BUFFER:  RDBCMM  RQSDSS        (ASCII)           (EBCDIC)
         0 1 2 3 4 5 6 7  8 9 A B C D E F   0123456789ABCDEF  0123456789ABCDEF
  0000  000AD00100010004 200E               ........ .        ..}.......
 
4       DB2 fnc_data      gateway_drda_ar      sqljcrecv (1.35.10.81)
        pid 95212; tid 537115484; node 0; cpid 0; sec 0; nsec 0; tpoint 178
 
        RECEIVE BUFFER:  ENDUOWRM RPYDSS    (ASCII)           (EBCDIC)
         0 1 2 3 4 5 6 7  8 9 A B C D E F   0123456789ABCDEF  0123456789ABCDEF
  0000  002BD05200010025 220C000611490004   .+.R...%"....I..  ..}.............
  0010  00162110E2C1D56D C6D9C1D5C3C9E2C3   ..!....m........  ....SAN_FRANCISC
  0020  D640404040400005 211501000BD00300   .@@@@@..!.......  O     .......}..
  0030  0100052408FF                        ...$..            ......
 
5       DB2 fnc_data      gateway_drda_ar      sqljmsca (1.35.10.108)
        pid 95212; tid 537115484; node 0; cpid 0; sec 0; nsec 0; tpoint 179
        SQLCA
 
        SQLCAID:  SQLCA
        SQLCABC:  136
        SQLCODE:  0
        SQLERRML: 0
        SQLERRMC:
        SQLERRP:  DSN
        SQLERRD[0->5]: 00000000, 00000000, 00000000, 00000000, 00000000, 00000000
        SQLWARN(0->A):  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,
        SQLSTATE: 00000

Abbildung 11. Beispiel einer Ablaufverfolgungsausgabe (TCP/IP-Verbindung)

1       DB2 fnc_data      gateway_drda_ar      sqljcsend (1.35.10.80)
        pid 80286; tid 537125164; node 0; cpid 0; sec 0; nsec 0; tpoint 177
 
        SEND BUFFER:  EXCSAT RQSDSS         (ASCII)           (EBCDIC)
         0 1 2 3 4 5 6 7  8 9 A B C D E F   0123456789ABCDEF  0123456789ABCDEF
  0000  006ED04100010068 10410020115E8482   .n.A...h.A. .^..  .>}..........;db
  0010  F282974040404040 4040404040404040   ...@@@@@@@@@@@@@  2bp
  0020  4040F0F0F0F1F3F9 F9C5000C116DA685   @@...........m..    0001399E..._we
  0030  81A2859340400013 115AC4C2F240C396   ....@@...Z...@..  asel  ...]DB2 Co
  0040  95958583A340F54B F200181404140300   .....@.K........  nnect 5.2.......
  0050  0514740005240700 05240F0003144000   ..t..$...$....@.  .............. .
  0060  05000D1147D8C4C2 F261F6F0F0F00010   ....G....a......  .....QDB2/6000..
  0070  D0410002000A106D 000611A20003003C   .A.....m.......<  }......_...s....
  0080  D04100030036106E 000611A200030016   .A...6.n........  }......>...s....
  0090  2110E2C1D56DC6D9 C1D5C3C9E2C3D640   !....m.........@  ..SAN_FRANCISCO
  00A0  40404040000C11A1 9781A2A2A6969984   @@@@............      ....password
  00B0  000A11A0A4A28599 8984009CD0010004   ................  ....userid..}...
  00C0  0096200100162110 E2C1D56DC6D9C1D5   .. ...!....m....  .o......SAN_FRAN
  00D0  C3C9E2C3D6404040 40400006210F2407   .....@@@@@..!.$.  CISCO     ......
  00E0  000D002FD8E3C4E2 D8D3C1E2C3000C11   .../............  ....QTDSQLASC...
  00F0  2EE2D8D3F0F5F0F2 F0003C210437E2D8   ..........
3       DB2 fnc_data      gateway_drda_ar      sqljcsend (1.35.10.80)
        pid 80286; tid 537125164; node 0; cpid 0; sec 0; nsec 0; tpoint 177
 
        SEND BUFFER:  RDBCMM  RQSDSS        (ASCII)           (EBCDIC)
         0 1 2 3 4 5 6 7  8 9 A B C D E F   0123456789ABCDEF  0123456789ABCDEF
  0000  000AD00100010004 200E               ........ .        ..}.......
 
4       DB2 fnc_data      gateway_drda_ar      sqljcrecv (1.35.10.81)
        pid 80286; tid 537125164; node 0; cpid 0; sec 0; nsec 0; tpoint 178
 
        RECEIVE BUFFER:  ENDUOWRM RPYDSS    (ASCII)           (EBCDIC)
         0 1 2 3 4 5 6 7  8 9 A B C D E F   0123456789ABCDEF  0123456789ABCDEF
  0000  002BD05200010025 220C000611490004   .+.R...%"....I..  ..}.............
  0010  00162110E2C1D56D C6D9C1D5C3C9E2C3   ..!....m........  ....SAN_FRANCISC
  0020  D640404040400005 211501000BD00300   .@@@@@..!.......  O     .......}..
  0030  0100052408FF                        ...$..            ......
 
5       DB2 fnc_data      gateway_drda_ar      sqljmsca (1.35.10.108)
        pid 80286; tid 537125164; node 0; cpid 0; sec 0; nsec 0; tpoint 179
        SQLCA
 
        SQLCAID:  SQLCA
        SQLCABC:  136
        SQLCODE:  0
        SQLERRML: 0
        SQLERRMC:
        SQLERRP:  DSN
        SQLERRD[0->5]: 00000000, 00000000, 00000000, 00000000, 00000000, 00000000
        SQLWARN(0->A):  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,
        SQLSTATE: 00000

Folgende Informationen werden bei der Ablaufverfolgung erfaßt:

Der erste Puffer enthält die Befehle EXCSAT (Exchange Server Attributes) und ACCRDB (Access RDB), die an das Verwaltungssystem des Datenbank-Servers auf dem Host oder System IBM AS/400 gesendet werden. Das Senden erfolgt als Ergebnis des Datenbankbefehls CONNECT TO.

Der nächste Puffer enthält die Antwort, die DB2 Connect vom Verwaltungssystem des Datenbank-Servers auf dem Host oder System IBM AS/400 empfing. Sie enthält EXCSATRD (Exchange Server Attributes Reply Data) und eine ACCRDBRM (Access RDB Reply Message).

Analysieren von EXCSAT und ACCRDB

Der Befehl EXCSAT enthält den Namen der Workstation des Clients, der vom Server-Namensobjekt (SRVNAM) angegeben wird; dieser Name entspricht gemäß der DDM-Spezifikation Codepunkt X'116D'. Der Befehl EXCSAT befindet sich im ersten Puffer. Im Befehl EXCSAT werden die Werte X'116DA68581A28593' (die in der ID 500 für den Zeichensatz codiert sind) in weasel umgesetzt, sobald X'116D' entfernt ist.

Der Befehl EXCSAT enthält ebenfalls das Objekt EXTNAM (externer Name), das oft in Diagnoseinformationen im Verwaltungssystem des Datenbank-Servers auf dem Host oder System IBM AS/400 zu finden ist. Es besteht aus einer 20 Byte langen Anwendungs-ID, gefolgt von einer 8 Byte langen Prozeß-ID (oder einer 4 Byte langen Prozeß-ID und einer 4 Byte langen Thread-ID). Es wird durch Codepunkt X'115E' dargestellt und hat in diesem Beispiel den Wert db2bp_32, der durch Leerzeichen aufgefüllt ist und auf den 0000BE5C folgt. Auf einem auf UNIX basierenden Datenbank-Client kann dieser Wert mit dem Befehl ps angezeigt werden, der Prozeßstatusinformationen zu aktiven Prozessen an die Standardausgabe übergibt.

Der Befehl ACCRDB enthält den RDB_NAME im Objekt RDBNAM (Codepunkt X'2110'). Der Befehl ACCRDB folgt auf den Befehl EXCSAT im ersten Puffer. Im Befehl ACCRDB werden die Werte X'2110E2C1D56DC6D9C1D5C3C9E2C3D6' in SAN_FRANCISCO umgesetzt, nachdem X'2110' entfernt wurde. Dies entspricht dem Feld für den Zieldatenbanknamen im DCS-Verzeichnis.

Die Abrechnungszeichenfolge hat den Codepunkt X'2104' (siehe Implementieren der Zurückbelastung unter DB2 Universal Database für OS/390).

Der codierte Zeichensatz für die DB2 Connect-Workstation kann ermittelt werden, indem das CCSID-Objekt CCSIDSBC (ID für codierten Zeichensatz für Einzelbytezeichen) mit Codepunkt X'119C' im Befehl ACCRDB gesucht wird. In diesem Beispiel ist der Wert für CCSIDSBC X'0352', d. h. 850.

Wenn die zusätzlichen Objekte CCSIDDBC (ID für codierten Zeichensatz für Doppelbytezeichen) und CCSIDMBC (ID für codierten Zeichensatz für Mischbytezeichen) mit dem Codepunkt X'119D' bzw. X'119E' vorhanden sind, ist die DB2 Connect-Workstation für die Unterstützung von DBCS-Codepages konfiguriert. Da die beiden zusätzlichen Codepunkte in der Beispielausgabe nicht enthalten sind, ist die Workstation nicht für DBCS konfiguriert.
Anmerkung:Der TCP/IP-Datenfluß enthält zwei neue Befehle: ACCSEC zum Zugriff auf den Sicherheitsmanager und zum Austausch unterstützter Sicherheitsmechanismen sowie SECCHK mit den Identifikationsüberprüfungs-Token, die zur Überprüfung des Endbenutzers für die Verbindung verwendet werden. ACCSEC und SECCHK erscheinen nur für TCP/IP-Verbindungen zwischen EXCSAT und ACCRDB.

Analysieren von EXCSATRD und ACCRDBRM

CCSID-Werte werden auch vom Host- oder AS/400-Datenbank-Server in ACCRDBRM (Access RDB Reply Message) im zweiten Puffer übergeben. Dieser Puffer enthält die EXCSATRD-Daten, gefolgt von den ACCRDBRM-Daten. Die Beispielausgabedatei enthält CCSID-Werte von 500 für das Datenbank-Server-System auf dem Host oder System IBM AS/400 (X'01F4', SBCS-CCSID).

Wenn DB2 Connect die Codepage, die vom Host- oder AS/400-Datenbank-Server zurückkommt, nicht erkennt, wird SQLCODE -332 mit den Codepages für Quelle und Ziel an den Benutzer übergeben. Wenn der Host- oder AS/400-Datenbank-Server den von DB2 Connect gesendeten codierten Zeichensatz nicht erkennt, übergibt er VALNSPRM (Parameterwert nicht unterstützt, DDM-Codepunkt X'1252'); diese Angaben werden für den Benutzer in SQLCODE -30073 umgesetzt.

Der Befehl ACCRDBRM enthält auch den Parameter PRDID (produktspezifische Kennung, Codepunkt X'112E'). Der Wert ist X'C4E2D5F0F5F0F1F0'. Diese hexadezimale Zeichenfolge entspricht der Angabe DSN05010 in EBCDIC. Gemäß den Standards entspricht DSN der Angabe DB2 für MVS/ESA oder DB2 Universal Database für OS/390. Die Version, 5.1, ist ebenfalls angegeben. ARI steht für DB2 für VSE & VM, SQL für DB2 Server-Plattform (DB2 Common Server) und QSQ für DB2 Universal Database für AS/400.

Analysieren der nachfolgenden Puffer

Auch die nachfolgenden Sende- und Empfangspuffer können auf zusätzliche Informationen hin analysiert werden. Der dritte Puffer enthält eine COMMIT-Operation. Der Befehl commit weist das Verwaltungssystem des Datenbank-Servers auf dem Host oder System IBM AS/400 an, die aktuelle Arbeitseinheit festzuschreiben. Der vierte Puffer wird vom Datenbankverwaltungssystem des Datenbank-Servers auf dem Host oder System IBM AS/400 als Ergebnis einer COMMIT- oder ROLLBACK-Operation empfangen. Er enthält die ENDUOWRM-Nachricht (End Unit of Work Reply Message), die anzeigt, daß die aktuelle Arbeitseinheit beendet wurde. In diesem Beispiel enthält er einen leeren SQL-Kommunikationsbereich, angezeigt durch Codepunkt X'2408' gefolgt von X'FF'. Ein leerer SQL-Kommunikationsbereich (X'2408FF') zeigt die erfolgreiche Ausführung an (SQLCODE 0). Wenn ein Empfangspuffer einen SQL-Kommunikationsbereich (auch einen leeren SQL-Kommunikationsbereich) enthält, wird von ddcstrc nach diesem Empfangspuffer eine formatierte Interpretation der Informationen des SQL-Kommunikationsbereichs ausgegeben.

In Abbildung 12 ist ein Beispiel eines Empfangspuffers mit einem SQL-Kommunikationsbereich, der auf einen Fehler hinweist, und einer formatierten Anzeige des SQL-Kommunikationsbereich dargestellt. Dieser SQL-Kommunikationsbereich stellt das Ergebnis eines Versuchs dar, Zeilen aus einer nicht vorhandenen Tabelle zu löschen.

Abbildung 12. Beispiel eines Empfangspuffers

1       DB2 fnc_data      gateway_drda_ar      sqljcrecv (1.35.10.81)
        pid 48732; tid 1; node 0; cpid 0; sec 0; nsec 0; tpoint 178        
 
        RECEIVE BUFFER:  SQLCARD OBJDSS     (ASCII)           (EBCDIC)
         0 1 2 3 4 5 6 7  8 9 A B C D E F   0123456789ABCDEF  0123456789ABCDEF
  0000  0065D0030001005F 240800FFFFFF34F4   .e....._$.....4.  ..}....^.......4
  0010  F2F7F0F4C4E2D5E7 D6E3D34000E2C1D5   ...........@....  2704DSNXOTL .SAN    
  0020  6DC6D9C1D5C3C9E2 C3D64040404040FF   m.........@@@@@.  _FRANCISCO     .    
  0030  FFFE0C0000000000 000000FFFFFFFF00   ................  ................    
  0040  0000000000000040 4040404040404040   .......@@@@@@@@@  .......    
  0050  40400000000FC4C4 C3E2E4E2F14BD4E8   @@...........K..    ....DDCSUS1.MY
  0060  E3C1C2D3C5                          .....             TABLE
               
2       DB2 fnc_data      gateway_drda_ar      sqljmsca (1.35.10.108) 
        pid 48732; tid 1; node 0; cpid 0; sec 0; nsec 0; tpoint 179             
        SQLCA
 
        SQLCAID:  SQLCA
        SQLCABC:  136                                                           
        SQLCODE:  -204                                                           
        SQLERRML: 15                                                            
        SQLERRMC: DDCSUS1.MYTABLE
        SQLERRP:  DSNXOTL                                                 
        SQLERRD[0->5]: FFFFFE0C, 00000000, 00000000, FFFFFFFF, 00000000, 00000000
        SQLWARN(0->A):  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,
        SQLSTATE: 42704


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]