Debugging einer RPGLE Anwendung mit RDI 9.0.3.6

[dschroeder]

Meine Frage ist eher, warum du das strdbgsvr überhaupt manuell eingibst? Das muss man normalerweise gar nicht machen! Was passiert denn, wenn du das nicht machst, sondern einfach ein Programm debuggst? Um das Starten von Servern kümmert sich RDi schon selber.

Wenn ich im RDi ein Programm debuggen will, kümmere ich mich gar nicht um irgendwelche Debug Server. Ich lasse mir die Member einfach in der Objekttabelle anzeigen, drücke auf dem entsprechenden Member die rechte Maustaste und setze einen Service-Entry Point. Das war's.

Vielleicht kannst du mal ein paar Screenshots senden, was du genau tust. (Ich nutze für so etwas immer das Snipping Tool von Windows. Da kann man auch eine Verzögerung für den Screenshot einstellen, um Aufnahmen von Kontextmenüs zu machen. Das Menü verschwindet sonst immer, wenn man die Maus auf das Snipping Tool bewegt und dort klickt).

[Radinator]

Der Grund, warum ich den Befehl selber eingebe, ist nur der, weil ich mal schauen wollte ob die manuelle Eingabe des Befehls ein anderes Verhalten zeigt, als wenn ich den Debug Server durch das RDI GUI starten lasse.
"Das Programm einfach debuggen" ist deswegen leichter gesagt als getan, weil ich eben erst einmal den verdammten Debug Server zum laufen bringen muss. Solange der nicht arbeitet, kann ich das debuggen vergessen. Deswegen hab ich auch so einen langen Artikel geschrieben. Denn das Problem ist in bisher allen Einträgen, die ich zu dem Thema verfasst habe, hat sich jeder bisher nur auf das Debuggen an sich konzentriert und nicht darauf, warum der Debug Sever sich nicht zum laufen überreden lässt.

Meine Frage ist deswegen auch an dich @dschroeder: Wenn du im Green Screen den Befehl eingibst, ist die Sitzung dann auch bei dir blockiert oder ist das nur ein Aufruf eines Programms, das nach wenigen Sekunden durch ist und du kannst die Session ganz normal verwenden?
Denn ich habe eben die Vermutung, dass das eben im Normalfall so ist, der STRDBGSVR jedoch auf irgendetwas zugreift, die Ressource jedoch nicht verfügbar ist und darauf gewartet wird. Kommt halt leider nur keine Fehlermeldung daher (aus welchem Grund auch immer)

Lg

[dschroeder]

Ich kann den Befehl STRDBGSVR im Green Screen eingeben und bekomme sofort eine Rückmeldung. Entweder "Router-Funktion des Testhilfe-Servers bereits aktiv." oder (nachdem ich den dbgsvr beendet habe und es neu starte): "Testhilfe-Server wurde gestartet.". Das dauert keine halbe Sekunde.

Kannst du den interaktive Job, in dem du den Befehl eingibst, von einer anderen Sitzung aus beoachten? Vielleicht sieht man am Programmstapel, was er da gerade versucht. Im Joblog steht wahrscheinlich auch nichts?

[dschroeder]

In meinem Log steht danach folgendes:
STRDBGSVR
Eigentumsrecht für Objekt QB5ROUTER in QGPL Art *DTAQ geändert.
Objekt QB5ROUTER der Art *DTAQ in Bibliothek QGPL erstellt.
Job 411112/SCHRO970/QB5ROUTER an Jobwarteschlange QUSRNOMAX in Bibliothek
QSYS übergeben.
Objekt QB5ROUTER in QGPL Art *DTAQ wurde gelöscht.
Testhilfe-Server wurde gestartet.


Vielleicht fehlt ein Recht auf der QGPL oder die DTAQ ist locked? Oder es gibt keine passende JobQ ?

ich kann da leider auch nur raten.

[Radinator]

Also wenn ich, wie von dir beschrieben mit der einen Sitzung den Befehl STRDBGSVR ausführe und mir mit einer zweiten Sitzung über DSPJOBLOG die Eingaben ansehe wird mir nur der Aufruf von STRDBGSVR und uim Anschluss die Meldung "Job 918309/USER/QB5ROUTER wurde an Jobwarteschlange QUSRNOMAX in Bibliothek QSYS übergeben"

Aber nachdem Du mir mit deiner Aussage, dass bei Dir nach der Eingabe im Green Screen sofort eine Antwort kommt, bestätigt hast, dass das Verhalten auf meiner Kiste eher unüblich ist, denke ich wirklich, dass der Aufruf des Commands auf irgendeine Ressource wartet und einfach nur keine Fehlermeldung erzeugt.
Blöderweise, wenn ich mir die Sperren für den QPADEVXXXX Job ansehe, welcher den Aufruf des Commands macht, dann sehe ich nur die Sperren auf das Main *MENU, *USRPRF, *MSGQ, *DEVD, die *LIBs ein *FILE-DSP und zwei *PNLGRP.

Hatte auch schon im Vermutung, dass ein von mir mithilfe der Client Access DLL cwbx erstellen .NET Anwendung, welches eine Verbindung zur AS400 aufbaut und ein Programm aufruft, für die Sperre des STRDBGSVR verantwortlich ist.

Was mir aber auch noch aufgefallen ist: Egal von wo aus ich das Command aufrufe, nach (auf die Sekunde genau) exakt 10 Minunten ist das Command dann fertig und sperrt mir nich mehr die Eingabe. Im Joblog steht dann auch wie bei dir die Zeile, dass QB5ROUTER in QGPL Art *DTAQ gelöscht wurde, nur fehlt die letzt Zeile.

Weiterhin seltsam ist ja, bei dir steht
1.) STRDBGSVR
2.) Eigentumsrecht für Objekt QB5ROUTER in QGPL Art *DTAQ geändert.
3.) Objekt QB5ROUTER der Art *DTAQ in Bibliothek QGPL erstellt.
4.) Job 411112/SCHRO970/QB5ROUTER an Jobwarteschlange QUSRNOMAX in Bibliothek
QSYS übergeben.
5.) Objekt QB5ROUTER in QGPL Art *DTAQ wurde gelöscht.
6.) Testhilfe-Server wurde gestartet
Bei mir sind nur 1.), 3.), 4.) und 5.) drinnen, wenn ich das Ganze wie gesagt für die 10 Minuten laufen lasse und nicht vorher den Job kille.

[dschroeder]

Ich habe mal folgendes bei Google gefunden:

Klingt nach einer Firewall, die die Verbindung zu den Debug-Servern verhindert. ObjectsKlicken Sie mit der rechten Maustaste auf den Knoten Ihrer Verbindung in RDi, und wählen SieVerify Connection... - Charles May 23 um 17:54 aus

Versuch doch mal, die Connection von RDi aus zu verifizieren.

[Radinator]

Ist bereits erledigt, Verify Connection hat mir am Anfag nur gesagt dass die zwei PTFs, die im darauf folgenden Kommentar von mir erwähnt werden, fehlen. Wurden beide installiert.

Output:

Verbindung zu Zentralservice . . . . . . . . . . . . . .erfolgreich
Verbindung zu Befehlsservice . . . . . . . . . . . . . .erfolgreich
Verbindung zu Datenwarteschlangenservice . .erfolgreich
Verbindung zu Dateiservice . . . . . . . . . . . . . . . .erfolgreich
Verbindung zu Satzzugriffsservice . . . . . . . . .erfolgreich
Verbindung zu Anmeldeservice . . . . . . . . . . . . . .erfolgreich
Überprüfung der PTFs
    Rational Developer for i . . erfolgreich
        Remote System Explorer . . erfolgreich
            Produkt 5770WDS gefunden
                Option 60 gefunden
                    PTF SI55236 erfolgreich
                    PTF SI64924 erfolgreich
                    PTF SI52577 erfolgreich
                    PTF SI60690 erfolgreich
            Produkt 5770SS1 gefunden
                PTF SI53107 erfolgreich
                PTF SI62949 erfolgreich
        IBM i Integrated Debugger . . erfolgreich
            Produkt 5770SS1 gefunden
                PTF SI57638 erfolgreich
                PTF SI63271 erfolgreich
                PTF SI63708 erfolgreich
                PTF SI60383 erfolgreich
Server-Callbacks überprüfen
    Callback an RSE-Dämon überprüfen
        Callback an 192.168.102.70 an Port 4300 erfolgreich

[dschroeder]

Dann habe ich auch nur noch die Idee, das Problem bei IBM zu melden. Mit einem Wartungsvertrag ist das unproblematisch. Falls das nicht geht: Es gibt ja noch das offizielle IBM Forum für RDi:
https://www.ibm.com/developerworks/c...0-000000002285