Von Robert Gezelter
Wir sind eine facettenreiche Gruppe. Einige IT-Profis verbringen ihre gesamte Zeit damit, Software zu entwickeln. Andere sehen nie den Quelltext eines Programms, abgesehen von Skriptsprachen wie DCL oder Perl, außerhalb eines Lehrbuchs. Wiede andere sind nur mit dem operativen Geschäft befasst und haben gar kein Interesse an der Programmierung.
In dieser Reihe wird es mehrere rote Fäden geben. Eine Artikelserie wird sich mit Themen befassen, die für Entwickler von Interesse sind. Eine weitere wird den Schwerpunkt auf DCL und andere Skriptsprachen auf OpenVMS legen. Management und Abläufe wird das Thema einer dritten Reihe sein. Und es wird weitere Themen geben.
Dieser Artikel ist der erste einer Serie über die Fähigkeiten und Benutzung des OpenVMS-Debuggers DEBUG. Die OpenVMS Dokumentation behandelt DEBUG ausführlich im "HP OpenVMS Debugger Manual", das auf dem OpenVMS-Website in HTML und PDF vorhanden ist.
DEBUG ist eines der wesentlichen Werkzeuge in der Softwareentwicklung auf OpenVMS. Auf einer elementaren Ebene erlaubt es DEBUG dem Programmierer, die Programmausführung an ausgewählten Stellen des Quellprogramms zu unterbrechen, Variablen anzuzeigen und evtl. zu ändern, und die Verarbeitung fortzusetzen.
Sogar diese extrem begrenzte Nutzung von DEBUG ist ein Quantensprung, verglichen mit dem Einfügen und Entfernen von "print"-Anweisungen zum Zweck des Debuggens. Die Fähigkeit, Breakpoints zu setzen und Speicher zu betrachten ist ein grundlegender Aspekt des Debuggens, der weit vor die VAX zurückreicht.
Es ist einfach, DEBUG mit einem Programm zu nutzen. Die grundlegenden Schritte sind auf allen OpenVMS-Plattformen die gleichen:
- kompilieren mit den Qualifiern /DEBUG und /NOOPTIMIZE (DEBUG kann auch mit optimierten Code genutzt werden, es ist aber - manchmal viel - schwieriger, Quellcode mit ausführbarem Code in Beziehung zu setzen, wenn ohne /NOOPTIMIZE gearbeitet wird)
- linken mit dem Qualifier /DEBUG
- ausführen des Programms mit dem Kommando RUN
Bei Aktivierung des Programm-Images erhält zunächst DEBUG die Kontrolle, welches dann das eigentliche Benutzer-Image aufruft.
Im einfachsten Fall kann DEBUG mit dem Kommando GO angewiesen werden, das Programm einfach auszuführen. Bei Beendigung des Programm kehrt die Kontrolle zu DEBUG zurück, und der Benutzer bekommt den Prompt DBG> (Dieser Prozess kann automatisiert werden, was Thema einer zukünftigen Kolumne sein wird).
Es gibt mindestens vier verschiedene Verfahren für einen Benutzer, DEBUG im User-Mode zu verwenden. Die grundlegendste Schnittstelle zu DEBUG ist der ursprüngliche Zeile-für-Zeile-Modus, der im wesentlichen seit der Original-Release von VAX/VMS 1977 unverändert ist. DEBUG ist seit dieser Zeit nicht stehengeblieben. In den drei Dekaden seither ist dazugekommen: Vollbild-Modus (Kap. 7), DECwindows-Support (Teil III, Kap. 8 ff.) und Support für PC-Clients (Teil IV, Kap. 11). Während die Mechanismen sich leicht unterscheiden, bleiben die zugrundeliegenden Stärken von OpenVMS DEBUG die gleichen.
Es lohnt sich, mit einem extrem einfachen Beispiel der Benutzung von DEBUG zu beginnen. Um sicherzustellen, dass das Beispiel auch mit einer Grund-Installation irgendeiner Version von OpenVMS läuft, wird diese Kolumne MACRO-32 für die Beispiele verwenden. MACRO-32 ist die symbolische Version des VAX-eigenen Befehlssatzes. Auf VAX-Prozessoren ist MACRO-32 der klassische Makro-Assembler; auf Alpha und Itanium wird MACRO-32 mittels architekturabhängiger Compiler in gleichwertige Programme übersetzt (AMACRO für Alpha, IMACRO für Itanium). Während heutzutage MACRO-32 kaum noch verwendet wird, hat es den Vorteil, dass der benötigte Assembler/Compiler Teil der Basis-OpenVMS-Distribution ist, so dass die Beispiele mit jedem OpenVMS-System verwendet werden können. (Versionen von entsprechenden Beispielprogrammen in anderen populären Sprachen sind verfügbar)
.ENTRY TEST,^M
MOVZBL #157,STATUS ; Setzt den Wert von STATUS auf 157
MOVZBL #SS$_NORMAL,R0 ; Setzt den "Erfolgs"-Rückgabewert.
RET ; Rückkehr zum Aufrufenden.
.PSECT DATA,WRT,NOSHR
STATUS: .BLKL 1 ; Speicherplatz für 1 Langwort (32 bit).
.END TEST
Dieses Quellprogramm muss assembliert werden (kompiliert auf Alpha und Itanium). Das DCL-Kommando dazu ist in allen Fällen das gleiche: $ MACRO/DEBUG [/NOOPTIMIZE] TEST (auf Alpha/Itanium mit /NOOPTIMIZE). Als nächstes muss die Objekt-Datei in ein ausführbares Image verwandelt werden, mithilfe des OpenVMS LINKERs. Das DCL-Kommando dafür ist: $ LINK/DEBUG TEST.
Das DCL-Kommando $ RUN TEST schließlich startet das erzeugte Image mit aktiviertem DEBUG.
Am Prompt DBG> geben Sie SET BREAK %LINE 2 ein, gefolgt von der ENTER-Taste, dann SET BREAK %LINE 3 und ENTER-Taste. DEBUG bekommt vor der ersten ausführbaren Anweisung die Kontrolle (auf VAXen ist dies Zeile 10, die erste MOVZBL-Instruktion, auf Alpha/Integrity die erste ausführbare Instruktion der erzeugten Präamble, so dass die erste ausführbare Instruktion die .ENTRY-Anweisung zu sein scheint). Um die Ausführung des Programms zu beginnen, geben Sie STEP ein.
Danach sollte DEBUG vor der ersten ausführbaren Zeile des Programms (Zeile 10; MOVZBL #157,STATUS) stehen. Übrigens ist die Groß-/Kleinschreibung der Symbole nicht wichtig, weil die Objekt-Datei in MACRO-32 ist, im Gegensatz zu C, C++ und verwandten Sprachen. Geben Sie das Kommando EXAMINE STATUS ein, um den aktuellen Wert zu sehen, der in STATUS gespeichert ist. Dieser sollte 0 sein (auf OpenVMS wird nicht initialisierter Speicher aus Sicherheitsgründen mit Nullen belegt). Geben Sie nochmals STEP, um die nächste Quell-Anweisung auszuführen. DEBUG wird sich zurückmelden mit break at %line 11. Nun geben Sie nochmals das Kommando EXAMINE/DECIMAL STATUS ein; der Wert wird jetzt 157 sein (in Dezimalschreibweise, weil wir /DECIMAL beim EXAMINE-Kommando angegeben haben).
Jetzt tippen Sie GO, und das Programm wird die Ausführung beenden, und zum Prompt DBG> zurückkehren. Ctrl-Z (oder EXIT) gibt die Kontrolle an DCL zurück. Eine Log-Datei des gesamten Dialogs ist in den Beispiel-Archiven enthalten, genau wie eine DCL-Kommandodatei, die das gesamte Beispiel ausführt. In kommenden Kolumnen dieses Teils der Serie werden wir aufwendigere Beispiele dafür zeigen, wie DEBUG vorteilhaft benutzt werden kann.
Leserfragen zur Verwendung von DEBUG und andere, auf OpenVMS bezogene Fragen sollten an OpenVMSConsultant (at) OpenVMS.org adressiert werden. Obwohl ich nicht versprechen kann, alle Nachrichten zu beantworten, werde ich es versuchen, wie es meine Zeit erlaubt. Der OpenVMS-Fachberater begrüßt Fragen von Lesern über OpenVMS und verwandte Technologien. Bitte senden Sie Ihre Fragen an den OpenVMS Consultant.
Über den Autor:
Robert Gezelter, CDP, CSA, CSE, Software Consultant, Gastredner und technischer Unterstützer, hat mehr als 30 Jahre internationale Erfahrung mit der Fachberatung im privaten und öffentlichen Sektor. Er ist regelmäßiger Gastredner auf technischen Konferenzen weltweit, wie dem HP Technology Forum und der HPWORLD. 2004 hat die IEEE Computer Society Mr. Gezelter in ihr Distinguished Visitors Program berufen, das Redner auf Veranstaltungen von IEEE-Verbänden in ganz Nordamerika vermittelt.
Kürzlich hat er begonnen, Ruminations - An IT Blog über IT-Themen zu schreiben, die nicht mit OpenVMS in Verbindung stehen.
Die Tätigkeit seiner Firma betont detaillierte technische Expertise in den Bereichen Computer-Architekturen, Betriebssysteme, Netzwerke, Sicherheit, APIs und verwandte Themen. Mr. Gezelter hat mit OpenVMS seit der ersten Release von VAX/VMS 1977 gearbeitet.
Seine Kundenstamm umfasst sowohl kleinere Firmen wie auch Firmen in den Fortune 10, lokal, national und international, mit Arbeitsbereichen, die von individuellen Telefon-Fragen bis zu größeren Projekten reichen.
Im Web ist er unter http://www.rlgsc.com zu erreichen.
Original auf www.openvms.org
|