Debugger - Release-Informationen

1.0 Einführung
2.0 Bekannte Probleme
   2.1 Web-Entwicklungsumgebung
   2.2 Debug von WebSphere Application Server
   2.3 JavaScript-Debugger
   2.4 SQL - Gespeicherte Prozeduren - Debugger
   2.5 Tools für Test und Implementierung (Servertools)
   2.6 Java Development Tools (JDT) - Debugger
   2.7 Einschränkungen bei Landessprachen
   2.8 SQL - Gespeicherte Prozeduren - Debugger (Linux)
   2.9 SQLJ - Debugger

1.0 Einführung

Die Debugger in WebSphere Studio bieten die Tools, die zum Debug von Webanwendungen, serverseitigem JavaScript, Java, SQLJ, gespeicherten SQL-Prozeduren und Compilersprachen benötigt werden. In dieser Readme-Datei werden die bekannten Probleme und Einschränkungen hinsichtlich der WebSphere Studio-Debugger beschrieben.

2.0 Bekannte Probleme

2.1 Web-Entwicklungsumgebung

JSP-Debug:

2.2 Debug von WebSphere Application Server

2.3 JavaScript-Debugger

2.4 SQL - Gespeicherte Prozeduren - Debugger

2.5 Tools für Test und Implementierung (Servertools)

Beachten Sie folgende Punkte, wenn Sie einen Server im Debug-Modus ausführen wollen:

2.6 Java Development Tools (JDT) - Debugger

Informationen zu den bekannten Problemen und Einschränkungen in Verbindung mit den Java-Entwicklungstools enthalten die Release-Informationen zu den Java Development Tools (JDT) und der Workbench (IDE). Diese können über eine Verknüpfung in der Readme-Hauptdatei des Produkts aufgerufen werden, die zusammen mit diesem Produkt installiert wurde.

2.7 Einschränkungen für Landessprachen

2.8 SQL - Gespeicherte Prozeduren - Debugger (Linux)

Wenn Sie ein Debug einer gespeicherten SQL-Prozedur auf einer lokalen Datenbank ausführen, wird möglicherweise der Fehler mit der Nummer SQL1224N angezeigt:

COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command. SQLSTATE=55032

(COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI-Treiber] SQL1224N Ein Datenbankagent konnte nicht zur Bearbeitung einer Anforderung gestartet werden oder wurde als Reaktion auf das Herunterfahren eines Datenbanksystems oder auf einen verbindlichen Befehl beendet. SQLSTATE=55032)

Dieser Fehler wird durch ein Problem im Linux-Kernel ausgelöst (Bugzilla für Linux-Kernel Programmfehler #351). Die folgenden Anweisungen ermöglichen eine Umgehung, bei der an Stelle der Call Level Interface (CLI) die TCPIP-Verbindungsmethode von DB2 (als Loopback-Adresse) verwendet wird. Diese Prozedur ermöglicht dem Debugger die Verwendung desselben Datenbankaliasnamen wie zuvor:

  1. Wurde kein Port für ferne DB2-Clients eingerichtet, erstellen Sie im Verzeichnis /etc/services einen TCP/IP-Port (zum Beispiel db2cdb2inst1 50000/tcp # Port für DB2-Verbindungsservice). Es kann ein vorhandener Port für ferne DB2-Clients verwendet werden.

    Zum Ausführen der Schritte 2 bis 7 müssen Sie als DB2-Exemplareigner angemeldet sein.

  2. Konfigurieren Sie den Datenbankmanager, um den Verbindungsmanager für das TCP/IP-Übertragungsprotokoll zu starten. Falls Sie nicht sicher sind, ob dies bereits erfolgt ist, geben Sie den folgenden Befehl aus:
    db2set db2comm

    Sollte die Ausgabe nicht das Schlüsselwort tcpip enthalten, müssen Sie den folgenden Befehl eingeben, damit die Registrierungsdatenbankvariable db2comm aktualisiert wird und künftig tcpip enthält:

    db2set db2comm=<namen vorhandener protokolle>,tcpip

    Die Registrierungsdatenbankvariable db2comm legt fest, welcher Verbindungsmanager von welchem Protokoll aktiviert wird, wenn der Datenbankmanager gestartet wird. Diese Variable kann für mehrere Übertragungsprotokolle definiert werden, indem die einzelnen Schlüsselwörter wie in dem folgenden Beispiel mit Kommas voneinander getrennt werden: db2set db2comm=tcpip,appc.

    Damit die Verbindungsmanager für diejenigen Protokolle gestartet werden, die durch den Registrierungsparameter db2comm angegeben werden, müssen Sie den Befehl db2start erneut ausgeben. Da DB2 weiter unten in Schritt 7 neu gestartet wird, kann zum jetzigen Zeitpunkt darauf verzichtet werden.

    .
  3. Aktualisieren Sie den Parameter SVCENAME für die Datenbankkonfiguration mit dem Namen des Verbindungsservices, der in /etc/services definiert wurde (Schritt 1).

    Um die aktuelle Einstellung für den Parameter SVCENAME zu prüfen, geben Sie den folgenden Befehl ein:

    db2 get dbm cfg | grep -i svcename

    Falls die aktuelle Einstellung von SVCENAME aktualisiert werden soll, geben Sie den folgenden Befehl ein:

    db2 update dbm cfg using svcename <name des verbindungsservices>

    Hierbei gilt, dass bei <name des verbindungsservices> die Groß-/Kleinschreibung berücksichtigt werden und mit dem Namen des Serviceports übereinstimmen muss, den Sie in /etc/services angegeben haben (zum Beispiel db2 update dbm cfg using svcename db2cdb2inst1).

    Die Aktualisierung der Datenbankmanagerkonfiguration tritt erst nach der nächsten Ausgabe des Befehls db2start in Kraft. Dies erfolgt weiter unten in Schritt 7.

  4. Katalogisieren Sie den Loopback-Knoten, indem Sie den folgenden Befehl eingeben:
    db2 catalog tcpip node <knotenname> remote 127.0.0.1 server <name des verbindungsservices>

    Hierbei ist <knotenname> ein lokaler Aliasname für den Knoten, der katalogisiert werden soll. Dies ist beliebiger Name auf der Workstation, der den Knoten kennzeichnet (zum Beispiel db2 catalog tcpip node meinknoten remote 127.0.0.1 server db2cdb2inst1).

    Um zu prüfen, ob der Katalogisierungsbefehl korrekt funktioniert hat, geben Sie den folgenden Befehl aus:

    db2 list node directory

    Die Ausgabe, die auf diesen Befehl erfolgt, sieht folgendermaßen aus (Leerzeilen wurden zwecks besserer Lesbarkeit entfernt):

    Knotenverzeichnis
    Anzahl von Einträgen im Verzeichnis = 1
    Knoten 1 - Eintrag:
    Knotenname = MEINKNOTEN
    Kommentar =
    Protokoll = TCPIP
    Hostname = 127.0.0.1
    Servicename = db2cdb2inst1
  5. Katalogisieren Sie die Datenbank wie folgt. Beachten Sie die unten angegebenen Befehle zum Generieren einer Beispielausgabe, um die Auswirkungen jedes einzelnen Befehls zu verfolgen:
    1. db2 catalog db <datenbankname> as <aliasname der datenbank>
    2. db2 uncatalog db <datenbankname>
    3. db2 catalog db <aliasname der datenbank> as <datenbankname> at node <knotenname>
    Beispiel:
    db2 catalog db WAS as WASLOOP
    db2 uncatalog db WAS
    db2 catalog db WASLOOP as WAS at node MEINKNOTEN

    Hinweise:

    • Der Aliasname der Datenbank kann jeder beliebiger Name sein. Er darf jedoch nicht nicht identisch mit dem Namen der Datenbank sein.
    • Falls Sie die Datenbank nicht korrekt katalogisiert haben, wird der Fehler mit der Nummer SQL1334N gemeldet.
    • Die Schritte 5 a bis 5 c müssen für jede Datenbank wiederholt werden, auf der Sie ein Debug für eine gespeicherte Prozedur ausführen wollen.

    Beispielausgabe für die Schritte 5 a bis 5 c

    Vor Schritt 5 a wurde bereits eine lokale Datenbank mit dem Namen WAS erstellt. Der Befehl db2 list db directory führt zu folgender Ausgabe:

    Systemdatenbankverzeichnis
    Anzahl von Einträgen im Verzeichnis = 1

    Datenbank 1 - Eintrag:

    Datenbankaliasname = WAS
    Datenbankname = WAS
    Lokales Datenbankverzeichnis = /home/ctsui
    Datenbankreleasestufe = 9.00
    Kommentar =
    Verzeichniseintragstyp = Indirekt
    Katalogknotennummer = 0

    Nach Schritt 5 a hat die Eingabe des Befehls db2 list db directory die folgende Ausgabe zur Folge:

    Systemdatenbankverzeichnis
    Anzahl von Einträgen im Verzeichnis = 2

    Datenbank 1 - Eintrag:

    Datenbankaliasname = WAS
    Datenbankname = WAS
    Lokales Datenbankverzeichnis = /home/ctsui
    Datenbankreleasestufe = 9.00
    Kommentar =
    Verzeichniseintragstyp = Indirekt
    Katalogknotennummer = 0

    Datenbank 2 - Eintrag:

    Datenbankaliasname = WASLOOP
    Datenbankname = WAS
    Lokales Datenbankverzeichnis = /home/ctsui
    Datenbankreleasestufe = 9.00
    Kommentar =
    Verzeichniseintragstyp = Indirekt
    Katalogknotennummer = 0

    Nach Schritt 5 b hat die Eingabe des Befehls db2 list db directory die folgende Ausgabe zur Folge:

    Systemdatenbankverzeichnis
    Anzahl von Einträgen im Verzeichnis = 1

    Datenbank 1 - Eintrag:

    Datenbankaliasname = WASLOOP
    Datenbankname = WAS
    Lokales Datenbankverzeichnis = /home/ctsui
    Datenbankreleasestufe = 9.00
    Kommentar =
    Verzeichniseintragstyp = Indirekt
    Katalogknotennummer = 0

    Nach Schritt 5 c hat die Eingabe des Befehls db2 list db directory die folgende Ausgabe zur Folge:

    Systemdatenbankverzeichnis
    Anzahl von Einträgen im Verzeichnis = 2

    Datenbank 1 - Eintrag:

    Datenbankaliasname = WAS
    Datenbankname = WASLOOP
    Knotenname = MEINKNOTEN
    Datenbankreleasestufe = 9.00
    Kommentar =
    Verzeichniseintragstyp = Fern
    Katalogknotennummer = -1

    Datenbank 2 - Eintrag:

    Datenbankaliasname = WASLOOP
    Datenbankname = WAS
    Lokales Datenbankverzeichnis = /home/ctsui
    Datenbankreleasestufe = 9.00
    Kommentar =
    Verzeichniseintragstyp = Indirekt
    Katalogknotennummer = 0

    Um zu prüfen, ob der Befehl catalog db korrekt funktioniert hat, geben Sie die folgenden zwei Befehle aus (und beachten Sie die Beispielausgabe unten):

    db2 connect to wasloop
    db2 connect to was

    Hierbei sollte db2 connect to wasloop die Verbindungsinformationen ausgeben und db2 connect to was sollte SQL1403N angeben.

    Beispielausgabe des Befehls db2 connect to wasloop:

    Databanktverbindungsinformationen
    Systemdatenbankverzeichnis

    Datenbankserver = DB2/6000 6.1.0
    SQL- Berechtigungs-ID = CTSUI
    Lokaler Datenbankaliasname = WASLOOP

    Beispielausgabe des Befehls db2 connect to was:

    SQL1403N The username and/or password supplied is incorrect. SQLSTATE=08004
    (SQL1403N Der angegebene Benutzername und/oder das angegebene Kennwort sind falsch. SQLSTATE=08004
  6. Aktualisieren Sie das Authentifizierungsverfahren zu Clientauthentifizierung. Geben Sie den folgenden Befehl ein:
    db2 update dbm cfg using authentication client

    Um zu prüfen, ob der Befehl korrekt funktioniert hat, zeigen Sie die neuen Einstellungen durch Eingabe des folgenden Befehls an:

    db2 get dbm cfg

    Beispielausgabe:

    ....
    Authentifizierung des Datenbankmanagers         (AUTHENTIFIZIERUNG) = CLIENT
    ....
  7. Starten Sie DB2 neu, damit der Verzeichniscache aktualisiert wird. Beispiel:
    db2stop
    db2start
  8. Bei WAS ist es nicht erforderlich, die Datei 'admin.config' zu aktualisieren. Bei einer Websphere-Anwendung ist es nicht erforderlich, die vorhandene Konfiguration für die Datenquelle zu ändern.
  9. Wenn Sie die Datenbank freigeben wollen, geben Sie die folgenden Befehlsfolgen ein:
    1. db2 attach to <knotenname> user <benutzer_id> using <kennwort>
    2. db2 drop db <datenbankname>
      Beispiel:
      db2 attach to MEINKNOTEN user meine_id using mein_kennwort
      db2 drop db WAS

2.9 SQLJ - Debugger

Beim Ausführen von Hot-Swap während des Debug mit der J9 JVM wird ein Dialogfenster mit dem Inhalt Veraltete Methoden im Stack angezeigt, falls sich SQLJ-Methoden im Stack für Aufrufe befinden. Ist der Hot-Swap für eien SQLJ-Klasse erfolgt, wird die Klasse in der JVM neu geladen, aber der neue Code wird erst dann ausgeführt, wenn eine Methode in der Klasse aufgerufen wird.

Wenn Sie einen Hot-Swap für eine SQLJ-Klasse ausführen, funktionieren möglicherweise während der aktuellen Debugsitzung die SQLJ-Unterbrechungspunkte für diese Klasse nicht.

Zurück zur Readme-Hauptdatei