Modul <-> Programm

[Tobse77]

Hallo zusammen,

fficeffice" />>>

seit 1 Jahr programmiere ich mit RPGIV, allerdings nicht im ILE-Konzept. Nun soll ich eine externe ILE-Anwendung modifizieren.

>>

Mein Einstiegspunkt ist ein Modul, dessen Hauptprogramm ich durch eine glückliche Namensgebung durch die Autoren, schnell ausfindig machen konnte. Mit dem Befehl DSPPGM fand ich heraus, dass dieses Programm 5 Module und 7 Serviceprogramme beinhaltet. Leider steht nicht dabei, welche dies sind.

>>

Nun meine 1. Frage: Gibt es einen AS/400-Befehl welcher, ähnlich wie DSPDBR, die Relationen von Modulen und Programmen anzeigt, so dass ich von einem bekannten Modul das übergeordnete Programm erfahre und umgekehrt von einem bekannten Programm die eingebetteten Module und Serviceprogramme angezeigt bekomme ??

>>

Meine 2. Frage: Ich möchte das besagte Modul debuggen. Situation: Programm = VOG143; 1. aufgerufenes Modul ist eine CL-Prozedur VOG143M0; hieraus wird „mein“ Modul VOG143M1 aufgerufen. Wie kann ich nun dem Debugger begreifbar machen, dass nicht das 1. Modul, sondern das er 2. (bzw. x-beliebige) Modul debuggen soll ??

>>

>>

Für eine schnelle Antwort wäre ich sehr dankbar, denn mein Chef möchte bis heute Abend von mir wissen, ob ich selbst Herr der Lage werde, oder ob er sich an den externen Dienstleister wenden muss.

>>

>>

Mit freundlichen Grüßen,

Tobias

[Fuerchau]

Per DSPPGM können die Module ausfindig gemacht werden (auf den weiteren Seiten). Eine Ausgabe in OUTFILE gibts leider nicht.
Für das Auffinden von Modulen gibts denn auch nur API's, die hier im Forum bereits diskutiert wurden.
Um ein Modul auszutauschen, reicht das Erstellen des Moduls, das Programm kann dann mittel UPDPGM verändert werden.
Um ein Modul zu debuggen muss beim CRTxxxMOD DEBUG(*SOURCE) angegeben werden, dann kann man mittels STRDBG das Programm debuggen und (ich glaube F15) in die entsprechende Modulquelle wechseln und dort dann Breakpoints setzen und Einzelschritt durchführen.
Es müssen nicht alle Module debugbar sein.

[BenderD]

Hallo,

ich halte mir diese Probleme auf einfache Weise vom Hals:
1. Bei mir sind alle Exporte/Importe eindeutig, indem ich bei der Angabe EXTPROC im Prototyp den Modulnamen als Prefix vor den Procedure Name stelle. (CLs verwende ich keine - alternativ APIs oder system)
2. Alle CALL Anweisungen werden per CALLP ausgeführt.

Auf dieser Basis zeigt mir DSPMOD DETAIL(*IMPORT) (der auch outfile erlaubt) alle Referenzen, die ich brauche. Mittels PDM kann man sich da auch alle Angaben mit ADD in einem Rutsch in ein Outfile geben lassen.

Von UPDPGM und solchen Sachen lasse ich konsequent die Finger - das vor sich herschieben des neu bindens verschlimmert allenfalls Probleme (weil man nicht mehr weiss, wie korrekt gebunden wird) indem es sie in die Zukunft verschiebt; das gehört für mich in die Schachtel "grober Unfug" in der sich bei mir auch schon Binder Language und LevelCheck No, egal ob für Signaturen von Programmen, Serviceprogrammen oder Dateien, befindet. Lieber den Binder arbeiten, als den Programmierer Fehler suchen lassen.
Probleme beim neu binden lassen sich sicher vermeiden, wenn man genau dokumentiert wie zu binden ist. Ganz einfach geht das, indem man beim CRTPGM alle Module und Serviceprogramme explizit benennnt und den kompletten Befehl als Kommentar in die Quelle des Moduls mit dem Program Entry Point (SRVPGM analog) reinschreibt. Um nicht immer aus der Quelle abtippen zu müsssen, habe ich mir einen kleinen Preprozessor geschrieben, der automatisch aus der Quelle den CompileBefehl ausliest und ausführt, habe ihn OpenSource gemacht und auf meine Webseite gestellt. Seitdem befinden sich Binding Directories bei mir in der Schachtel "mittelgrober Unfug". Wem das zu einfach ist, der kann auch ein Change Management System einsetzen.

Zu dem Debug noch eine Anmerkung: mit Step into (Shift step -> F21) kan man sich da auch durch hangeln.

BTW: Debug gehört für mich in die Schachtel "lästiger Unfug, den man manchmal trotzdem braucht"; zur Verifikation von Modulen taugt der jedenfalls nix - doch das sprengt so ein Posting nun doch bei weitem.

mfg

Dieter Bender

Per DSPPGM können die Module ausfindig gemacht werden (auf den weiteren Seiten). Eine Ausgabe in OUTFILE gibts leider nicht.
Für das Auffinden von Modulen gibts denn auch nur API's, die hier im Forum bereits diskutiert wurden.
Um ein Modul auszutauschen, reicht das Erstellen des Moduls, das Programm kann dann mittel UPDPGM verändert werden.
Um ein Modul zu debuggen muss beim CRTxxxMOD DEBUG(*SOURCE) angegeben werden, dann kann man mittels STRDBG das Programm debuggen und (ich glaube F15) in die entsprechende Modulquelle wechseln und dort dann Breakpoints setzen und Einzelschritt durchführen.
Es müssen nicht alle Module debugbar sein.

[Fuerchau]

Tja Dieter, das geht beim Modul aber schön wärs doch, per DSPPGM die Module in eine Outfile zu bekommen (schließlich kann ein Modul ja in zig Pgm'en stecken).
Und DSPMOD aus einem Programm ? Das wäre auch ne nette Funktion, nur leider sind die Imports/Exports im Pgm weg.

Und welcher SW-Lieferant rückt schon freiwillig seine Module mit raus.

[BenderD]

@Baldur: das mit den Modulen, das ist doch bei ILE nur mittelbar, importiert werden doch in Wirklichkeit Procedures und Variablen (Schublade "mittelgrober Unfug") und das von Modul zu Modul. Wenn man keinen Huddel veranstaltet, mit mehrfachen Exportnamen, dann reicht die Ausgabe von DSPMOD, um in einem Rutsch eine Crossreferenz in beiden Richtungen aufzubauen und wenn man huddelt, dann würde auch ein DSPPGM in ein OUTFILE nix helfen. Genauso ist es mit gewisser Saftwore (sorry: Vertipper) wenn ich die Module nicht habe, ist es auch Wurscht was wo reingebunden wurde!

mfg

Dieter

Tja Dieter, das geht beim Modul aber schön wärs doch, per DSPPGM die Module in eine Outfile zu bekommen (schließlich kann ein Modul ja in zig Pgm'en stecken).
Und DSPMOD aus einem Programm ? Das wäre auch ne nette Funktion, nur leider sind die Imports/Exports im Pgm weg.

Und welcher SW-Lieferant rückt schon freiwillig seine Module mit raus.