Deep Dive mit Klaus-Peter Luttkus: Wie der IBM i Debugger funktioniert…

Auch erfahrenen Programmierern unterlaufen gelegentlich logische Fehler. RDi ermöglicht es Ihnen, Fehler in Ihrem Programm schnell und problemlos zu finden. Neben den bereits besprochenen Werkzeugen (siehe Techknowletter) besitzt RDi auch einen voll in die Workbench integrierten Debugger, den sogenannten Integrierten IBM i Debugger.

Klicken Sie dafür die gewünschte Zeile im Editor an (es muss eine ausführbare Zeile sein) und wählen Sie dann Ausführen bis Position aus dem Kontextmenü des Editors oder Editorpräfixbereichs aus. Im Normalfall wird Ihr Programm vor der Ausführung der ausgewählten Zeile gestoppt. Es gibt allerdings Fälle, in denen das nicht passiert:

1. Der Debugger findet einen aktiven Unterbrechungspunkt bevor er die Zeile erreicht. Das kann ein Zeilen- oder Überwachungsunterbrechungspunkt sein.
2. Das Programm endet ohne die Zeile zu erreichen.

Zeilenunterbrechungspunkte können Sie durch Doppelklicken im Editorpräfixbereich setzen, aber auch über das Kontextmenü des Editors. Das funktioniert natürlich nur für ausführbare Zeilen. Alle Zeilenunterbrechungspunkte, die für Ihr Programm gesetzt sind, werden als Punkt mit einem Haken im Präfixbereich markiert und in der Sicht „Unterbrechungspunkte“ aufgelistet.

Über das Kontextmenü der Sicht „Unterbrechungspunkte“ können Sie außerdem den Assistenten Unterbrechungspunkt bearbeiten aufrufen, der es Ihnen erlaubt, Bedingungen für einen Unterbrechungspunkt festzulegen. Diese Bedingungen müssen erfüllt sein, um die Ausführung Ihres Programms zu stoppen.

 

Die erste Seite des Assistenten enthält die Informationen über Ihr Programm und die Zeilennummer, die Sie im Normalfall nicht zu ändern brauchen.

 

Auf der zweiten Seite – Optionale Parameter – können Sie die Bedingung angeben; entweder die Häufigkeit, mit der Ihr Programm an dieser Zeile angehalten werden soll, oder einen Ausdruck, der jedes Mal geprüft wird, bevor diese Zeile ausgeführt wird.

 

Wenn Sie zum Beispiel am Verhalten einer Schleife nur interessiert sind, wenn der Index von 99 auf 100 wechselt, können Sie das Von-Feld für Häufigkeit auf 99 setzen, um somit 98 Mal das Anhalten Ihres Programms zu überspringen. Entsprechend können Sie einen Ausdruck spezifizieren, etwa KDKDNR = 4711, der erfüllt sein muss, um die Ausführung Ihres Programms zu unterbrechen. Welche Art von Ausdrücken erlaubt ist, hängt davon ab, in welcher Programmiersprache Ihr Programm geschrieben ist.

Überwachungsunterbrechungspunkte können Sie zudem vom Kontextmenü des Editors aus und über die Sicht Unterbrechungspunkte setzen. Überwachungsunterbrechungspunkte sind nützlich, wenn Sie wissen wollen, wann sich der Wert einer Variablen ändert. Der Debugger stoppt das Programm, bevor die Anweisung ausgeführt wird, die derjenigen folgt, die die Änderung verursacht hat.

 

 

Um einen Überwachungsunterbrechungspunkt zu setzen, doppelklicken Sie am besten auf die Variable im Editor und wählen im Kontextmenü des Editors Überwachungsunterbrechungspunkt hinzufügen aus. Der Name der Variablen wird dann in den Assistenten übernommen. Und wenn Sie die Variable in ihrer gesamten Länge überwachen wollen (Standardwert 0 für Anzahl der zu überwachenden Byte), können Sie einfach auf Fertig stellen klicken. Das Feld Anzahl der zu überwachenden Byte müssen Sie nur ändern, wenn Sie mehr oder weniger Bytes überwachen wollen als die Variable von ihrer Definition her angibt. Wenn bei der Ausführung des Programms nun eine Änderung des Werts festgestellt wird, macht Sie eine Nachricht darauf aufmerksam.

Überwachungsunterbrechungspunkte sind besonders hilfreich, wenn Sie die Variable zugleich in der Sicht Überwachungen anzeigen und somit den Wert überprüfen oder ggf. ändern können. Das geht am einfachsten, wenn Sie das gleich erledigen, nachdem Sie den Überwachungsunterbrechungspunkt gesetzt haben. Die Variable ist dann schon angeklickt und Sie brauchen nur Ausdruck überwachen im Kontextmenü auszuwählen.

 

Alle überwachten Variablen werden in der Sicht Ausdruck überwachen angezeigt.

 

Dort können Sie auch den Wert der angezeigten Variablen ändern.

 

Doppelklicken auf einen Eintrag erzeugt ein Eingabefeld, in das Sie dann den neuen Wert eintragen können.

Beachten Sie auch, dass Felder, deren Werte sich seit dem letzten Stopp geändert haben, in Rot angezeigt und mit einem kleinen Delta-Zeichen versehen werden.

Mit diesen Informationen sind Sie für Ihre erste Debug-Sitzung gut gerüstet. Erlauben Sie mir noch eine Bemerkung zu Unterbrechungspunkten: Breakpoints können Sie direkt im LPEX-Editor erzeugen, indem Sie in einer Programmzeile vor das numerische Präfix doppelklicken.

Wichtig: Die bisher gezeigten Möglichkeiten des Debuggings beziehen sich auf alle OPM- und ILE-Sprachvarianten. Ich verwende diese traditionelle Art des Debuggens jedoch ausschließlich für OPM-Programme. Wie ich ILE-Programme umwandle, beschreibe ich im nächsten Abschnitt.

Service-Eingangspunkte

Service-Eingangspunkte stellen eine weitere Möglichkeit dar, Programme zu debuggen. Es muss sich bei den zu debuggenden Objekten jedoch um ILE-Programme handeln. Mit Service-Eingangspunkten können Sie sowohl interaktive als auch Stapelprogramme und -jobs debuggen. Darüber hinaus können Sie auf den unterschiedlichen ILE-Objektebenen debuggen: Sie können Programme und Serviceprogramme, Module und Prozeduren debuggen.

Die Arbeit mit Service-Eingangspunkten ist verglichen mit den vorgenannt beschriebenen Debugger-Aufrufen einfach und gradlinig. Befinden Sie sich in einer Debugging-Sitzung, können Sie die einzelnen Funktionen der Debugging-Perspektive beschrieben verwenden.

Da ich seit einigen Jahren ausschließlich im ILE-Umfeld tätig bin, stellt für mich das Debugging mit Service-Eingangspunkten die primäre Art des Debuggens dar.

Bevor Sie jedoch mit Service-Eingangspunkten zu arbeiten beginnen, sollten Sie sich im Menü Fenster –> Benutzervorgaben die Eigenschaften des IBM i-Debuggers ansehen.

 

Unter IBM i-Debug finden Sie einige Punkte, von denen Produktionsdateien aktualisieren mit Sicherheit der wichtigste ist. Umso mehr, als das die einzige Stelle ist, um diesen Parameter für Service-Eingangspunkte zu setzen.

Stellen Sie sich einmal vor, dass das von Ihnen erstellte Programm nicht das erste Programm im Aufrufstapel ist. Ein anderes, bereits ausgetestetes Programm ruft Ihr neues Programm auf. Sie wollen sicherlich nicht in einer Debug-Sitzung zuerst durch das erste Programm steppen, um dann Ihr neues Programm zu debuggen.

Wenn Sie also ausschließlich Ihr neues Programm debuggen wollen, so definieren Sie dafür einen eigenen Service-Eingangspunkt.

 

Rechtklicken Sie auf Programmobjekt –> Debug (Serviceeingang) –> Serviceeingangspunkt definieren.

 

Danach öffnet sich nach einer Erfolgsmeldung die Sicht Serviceeingangspunkt definieren.

Jetzt wechseln Sie in eine 5250-Bildschirmsitzung oder starten mit dem Befehl SBMJOB das zu debuggende Programm. Ich starte in diesem Beispiel mein Programm interaktiv. Daraufhin öffnet sich die Debugging-Perspektive und stellt Ihnen die bereits beschriebenen Degugging-Werkzeuge zur Verfügung.

Achten Sie darauf, dass Sie sich in dieser Sitzung mit dem gleichen Benutzer angemeldet haben wie in Ihrer RSE-Verbindung bzw. achten Sie darauf, dass der SBMJOB-Befehl unter dem gleichen Benutzer läuft wie Ihre RSE-Verbindung. Können Sie diese Forderung nicht erfüllen, müssen Sie zunächst die Standardeigenschaften des Service-Eingangspunkts bearbeiten.

Dazu öffnen Sie das Kontextmenü für den soeben erstellten Service-Eingangspunkt mit einem Rechtsklick.

 

Wählen Sie den Punkt Ändern.

Weitere Verarbeitungsmöglichkeiten sind hier:

• Definieren: einen neuen Serviceeingangspunkt erstellen
• Entfernen: einen Serviceeingangspunkt löschen
• Aktivieren/Inaktivieren: einen Serviceeingangspunkt abschalten bzw. anschalten
• Aktualisieren: einen Serviceeingangspunkt aktualisieren

Der letzte Punkt bedarf einer Erläuterung. Haben Sie während einer Debugging-Sitzung einen Fehler entdeckt und nach der Fehlerbehebung das Programm neu kompiliert, so gilt ein Serviceeingangspunkt als verfallen. Beim erneuten Start des jetzt korrigierten Programms würde sich der Debugger nicht mehr öffnen. Aktualisieren Sie nach der Neukompilation eines Programmes einen Serviceeingangspunkt, so wird auf die neue Version des Programms aktualisiert und der Debugger öffnet sich.

 

Ändern Sie dann den dem Service-Eingangspunkt zugeordneten Benutzer gemäß der Bildschirmsitzung bzw. gemäß dem Befehl SBMJOB. Mittels des Kontextmenüs für Service-Eingangspunkte aktualisieren Sie sodann den Service-Eingangspunkt. Rufen Sie anschließend das zu debuggende Programm im Bildschirm oder durch SBMJOB auf.

Besteht eine RSE-Verbindung, so wird automatisch die Perspektive Debug gestartet und Sie können Ihr Programm debuggen.

Gleichermaßen können Sie verfahren, wenn Stapeljobs debugged werden sollen. Wichtig ist hierbei wieder, dass der Job unter dem Benutzer läuft, der auch die RSE-Verbindung gestartet hat.

Achtung: Sie können einen Service-Eingangspunkt auch für bereits gestartete Programme erstellen. Erstellen Sie zum Beispiel einen Service-Eingangspunkt für ein bereits ausgeführtes Dialogprogramm, so springt an Ihrem Arbeitsplatz der Debugger bei der nächsten Benutzeraktion an. Das Programm wird dann in den Step-Modus gesetzt und Sie übernehmen die weitere Kontrolle über den Programmablauf. Auch bei Stapeljobs wird bei der Ausführung der logisch nächsten Anweisung das Programm in den Step-Modus gesetzt, so dass Sie die Kontrolle übernehmen.

Bereits laufende Jobs debuggen

Stellen Sie sich folgendes Szenario vor. Auf Ihrem System laufen eine ganz Reihe von asynchronen Jobs, die die Kommunikation zwischen IBM i und anderen Systemen steuern. Jetzt wird gemeldet, dass einer dieser Jobs Unregelmäßigkeiten aufweist.

Der betreffende Job hat folgende Kenndaten:

• Name: PIARTEXP
• Eigentümer: WW
• Jobnummer: 112255
• ausgeführtes Programm: ARTSCLNT

Der Job wird im Subsystem PIXIACCESS ausgeführt.

Keiner kann sich die Unregelmäßigkeiten erklären, da dieser Job bisher unauffällig war. Also wird beschlossen, dass das Programm ARTSCLNT debugged werden muss. Jedoch soll der Job nicht beendet und neu gestartet werden, da sich damit die Voraussetzungen der Ausführung ändern und möglicherweise keine Fehlerbedingung erzeugt werden kann.

Wie können Sie dieses Problem lösen? Ganz einfach!

Öffnen Sie in der Sicht Ferne Systeme des Remote System Explorers in Ihrer Verbindung das Verzeichnis Jobs.

 

Sie sehen im Verzeichnis Jobs –> Aktive Jobs das Subsystem PIXIACCESS. Direkt unterhalb von PIXIACCESS sehen Sie den Job 112255/WW/PIARTEXP.

Ich markiere diesen Job mit einem Rechtsklick.

 

Im Kontextmenü wähle ich die Funktion Debug als –> IBM i-Job.

Jetzt öffnet sich der Debugger.

 

Was passiert jetzt?

Das Programm, in unserem Fall ARTSCLNT, fällt sofort in den Step-into-Modus und bleibt vor dem Ausführen der logisch nächsten Zeile stehen. Wir können jetzt also dieses Programm wie gewohnt debuggen und hoffentlich die Ursache für die Fehlfunktion finden.

Klaus-Peter Luttkus ist IBM i-Berater, schreibt regelmäßig für den TechKnowLetter und kann live in der MIDRANGE ACADEMY erlebt werden.