ILE-RPG in Stapel debuggen

[rr2001]

ich gehe folgendermaßen vor:

strsrvjob...
strdbg programmname
dann erscheint die Source
möchte mit F6 Breakpoint hinzufügen ->folgende Meldung

Befehl nicht zulässig, solange gewarteter Job nicht aktiv ist.

sobald der Job aktiv ist und ich mit addbkp arbeiten möchte,
kommt die Fehlermeldung
Kein Standardprogramm vorhanden.

will ich dann mit chgdbg das Standardprogramm ändern,
kommt die Fehlermeldung
Programm xy in der OPM-Testhilfeumgebung nicht aktiv.

wenn ich addpgm mache kommt die Meldung
Befehl für Binderprogramme ungültig.

[Fuerchau]

Das ist das generelle Problem mit Batch-Debug.

Breakpoints können leider nur gesetzt werden, wenn der Job aktiv ist. Das hat mit ILE gar nichts zu tun.

Du musst den Job erst mal loslaufen lassen, bevor du Breakpoints setzt.
Da der Job aber ggf. schon fertig ist, bevor du die Chance hast, musst du dir eine sinnvolle Wartemöglichkeit einfallen lassen.

Z.B.:

Im Dialogjob einen ALCOBJ *EXCL auf ein Testobjekt machen.
Ein CLP submitten, dass auf das gleiche Objekt wartet.
Dann den Debugger starten und Breakpoints setzen.
Anschließend per DLCOBJ im Dialogjob das Objekt wieder freigeben.

Du kannst auch mit einer INQ-Nachricht (SNDPGMMSG) arbeiten, die ja auch auf eine Antwort wartet.

[rr2001]

so einfach ist das mit ILE? :-)

beim traditionellen RPG bleibt der Job vor Beginn stehen und man kann in aller Ruhe die Breakpoints setzen.

Mich würde interessieren, wie einfach die Vorgehensweise
von Bender sich diesbezüglich gestalten würde.

[Fuerchau]

Ich weiß nicht wie du das bei OPM-Programmen machst.
Aber Breakpoints wurden bei mir in inaktivem Job noch nie akzeptiert.

[Pikachu]

So müßte es gehen:

SBMJOB CMD(CALL PGM(Bibliothek/Programm)) Job(Name) HOLD(*YES)

STRSRVJOB JOB(Nummer/Benutzer/Name)
STRDBG PGM(Bibliothek/Programm)
F12=Wiederaufnehmen

RLSJOB JOB(Nummer/Benutzer/Name)
F10=Befehlseingabe
DSPMODSRC

F10=Step oder Unterbrechungspunkte setzen und F12=Wiederaufnehmen
F12=Abbrechen
Eingabetaste

Programm wie gewohnt warten
F3=Verlassen

ENDDBG
ENDSRVJOB

[Fuerchau]

Das Problem hier ist der RLSJOB, da hier der Job ja sofort startet und mein Programm ggf. schon fertig ist, bevor ich zu den nächsten Schritten komme.

[Pikachu]

Das Problem hier ist der RLSJOB, da hier der Job ja sofort startet und mein Programm ggf. schon fertig ist, bevor ich zu den nächsten Schritten komme.

Da hab ich wohl einen gut erzogenen Job erwischt, denn er fragt sofort nach dem RLSJOB nach, wie es weitergehen soll und wartet dann brav ab.

[Fuerchau]

Hm, dann werden ich das wohl nochmal ausprobieren müssen.
Bisher musste ich mir immer mit diesen Sperrmimiken helfen.

Mal sehen...

[rr2001]

wunderbare Antwort.

Funktioniert prächtig.
So hab ich mir das vorgestellt.

[jc_denton]

wow, das hört sich alles sehr kompliziert an.
versuch es doch mal mit "service entry points":
- strdbg "my_pgm"
- sbreak [zeilen-nr.]
- mit f12 wieder raus.

jetzt bekommt man eine bildschirmnachricht wenn dieses programm - von wo auch immer - gerufen wurde.

in einer zweiten sitzung dann folgendes ausführen (nachdem die meldung kam):
- strsrvjob [my_job]
- strdbg [my_pgm]
in der sitztung die die meldung zeigt:
- "enter" drücken

der debugger zeigt dann die stelle im pgm, an der man den sbreak gesetzt hat. jetzt kann man "normale" breakpoints setzen oder per f10 step-by-step durchgehen.

[mk]

Hi,


also das wusste ich auch noch nicht.

der sbreak ist genial. Super Tipp

gruss
Michael