[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Oct 2014
    Beiträge
    28

    Debugging einer RPGLE Anwendung mit RDI 9.0.3.6

    Hallo Leute!

    Ich melde mich nochmal aus lauter Verzweiflung, da ich einfach nicht weiter komme.

    Ich habe vor etwa eine halben Jahr schon mal hier nachgefragt, ob jemand weiß, warum ich mit RDI 9.0.3.6 kein Remote Debugging machen kann. Damals hab ich mich noch irgendwie auf das Debuggen an sich verschossen und bin da eben verzweifelt. Jetzt hab ich aktuell wieder Luft und kann mich dem Thema noch einmal annehmen.

    Ich habe dieses mal auch wieder mehrer Male versuch den Debug Server zum Laufen zu bekommen. Das ist angeblich ja ganz einfach. Laut allen Quellen, die ich bisher dazu gefunden habe muss man ja "nur" entweder im Green Screen oder über RDI den Befehl "STRDBGSVR" eingeben. Dann soll der Server laufen und man kann im RDI seine SEP Einträge setzen und definieren. Alternativ kann man auch das Eingeben des Befehls auch gleich lassen und entweder im RDI unter einem Subsystem (ich nehme immer "Objekte" her) im Kontextmenü über Ferne Server->Debug->Starten drücken oder nach dem Setzen des SEP den Debug Server gleich mit starten.
    Das wäre an sich auch nicht das Problem. Doch was mich wie gesagt schon seit einiger Zeit und jetzt mal wieder zur Weißglut bringt ist die Tatsache, dass sich bei mir das RDI "aufhängt" wie man umgangssprachlich so schön sagt. Auch wenn ich weiß, dass das fachterminologisch (toller Neologismus ;D) nicht ganz so sauber ist, denke ich, wir wissen alle was damit gemeint ist: Das Fenster/die Anwendung reagiert auf keine Eingaben mehr und/oder zeigt beim drauf rumklicken und bei Eingaben irgendwann (nach wenigen Sekunden) oben im Fenster die Zeichenkette "Keine Rückmeldung" an.

    Also noch mal alle Vorgehensweisen, die leider alle zum selben Ergebnis führen:
    1.) Subsystem "Objekte"->Debug->Starten
    2.) Subsystem "Objekte" -> Befehl eingeben -> "STRDBGSVR" als "Normal"
    3.) SEP erstellen und nachdem ich benachrichtigt und gefragt werde, ob ich den Debug Server starten will, "JA" anklicken
    4.) Im Green Screen den Befehl "STRDBGSVR" eigeben.

    Ich habe auch schon versucht den Befehl sowohl im RDI wie unter 2.) als "Stapel" einzugeben und den Befehl auch schon im Green Screen mit SubmitJob gestartet. Hat nur den Vorteil, dass mir halt im ersten Fall RDI nicht einfriert und im zweiten Fall die Emulation noch Eingaben erlaubt.
    "Eingaben erlaubt" deswegen, weil ich, wenn ich das Command direkt aufrufe, sich die Emulation wie ein "long running program" verhät. Also wie wenn man ein Programm aufruft, welches ewig läuft. Die Anzeige ist noch da, das Fenster zeigt auch kein "Keine Rückmeldung" an, ich kann nur halt nix eingeben.

    Daher eine Frage an alle, die diese Technik verwenden: Wenn ihr den Befehl in einer TN5250 Sitzung aufruft, könnt Ihr dann die Sitzung noch weiter verwenden oder müsst Ihr auch erst einen neue Sitzung aufmachen?
    Ich habe heute auch mal irgendwo in der Referenz für RDI 9.0.3.6 gelesen, man soll das Starten des Debug Servers in die IPL integrieren, dann spart man sich das händische Starten.

    Es geht noch weiter ;D
    Was ich eben festgestellt habe ist, dass das Starten des Debug Servers auf unserer Kiste doch ein etwas merkwürdiger Vorgang ist. Ebenfalls irgendwo heute gelesen, stand, dass der Server nur ein einziges mal gestartet werden kann/darf. Sonst kommt eine Meldung, dass bereits eine Instanz aktiv ist. Jetzt habe ich einfach mal spaßeshalber zwei Sitzungen aufgemacht und bei beiden den Befehl eingegeben. Ergebnis: Keine Meldung!
    Und wie gesagt, wenn ich auf der ersten Sitzung das Command in dem IBM Main Menü eingebe, dann bleibe ich auf der Ebene sitzen und es werden keine Eingaben registriert (kein F9, keine Tastenanschläge). Ich kann über einen Button in der Emulation (von Mochasoft die TN5250) eine Zahl eingeben (3) um im Endeffekt den Befehl "DSPJOB" auszuführen. Hier kann ich dann z.B über "10" mir den Joblog anzuzeigen, in dem nur drinnen steht, dass ich den Job "jobnbr/user/Q5ROUTER" an die Jobwarteschlage QUSRNOMAX übergeben habe. Weiter steht nix drinnen. (Gut...fast nix: davor steht noch der Aufruf von QGPL/STRDBGSVR).

    Hier meine Vermutung(en):
    Da im Green Screen der Aufruf des Starts des Debug Servers vom Verhalten einem Aufruf eines Programms, welches ewig braucht (weil z.B. auf einen gelockten Record in einer Datenbank zugegriffen wird) ähnelt, glaube ich fast schon daran, dass eine Ressource, welche gebraucht wird gelockt ist und das Timeout irgendwo bei 10 Minuten liegt und keine gescheite Fehlermeldung einprogrammiert ist. Daher ist es egal, ob ich das "Programm" über die Emulation aufrufe oder über das GUI. Der Prozess läuft und läuft und läuft und kommt nicht zum Ende.

    Deswegen wäre es cool, wenn das jemand entweder schon einmal erlebt hat oder den direkten Aufruf des Debug Servers mal nachstellen und beschreiben könnte, was auf seiner Maschine passiert. Also ob sich das Verhalten, wie ich es nach besten Kräften und Gewissen beschreiben habe, nachstellen lässt.

    Ich hoffe wirklich inständig, dass mir hier jemand helfen kann.

    Lg Radinator

    Edit: Muss man eigentlich noch irgendwelche (Debug-)Profile konfigurieren, bevor man ein Programm debuggen kann oder würde das mit einem Clean-Install auch funktionieren? Also auf einem komplett neuen Rechner nur RDI installieren, eine Connection einrichten und SEP erstellen?

  2. #2
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Ich glaube nicht, dass ich deine Ausführungen alle verstanden habe. Aber hier ein paar Anmerkungen, wie es bei uns problemlos läuft:


    • Wenn bei uns heute noch niemand den Debugger benutzt hat, ist der Debug-Server noch nicht gestartet. Das kann mir als Programmierer aber erstmal egal sein.
    • Wenn ich ein Programm debuggen will, mache ich folgendes:
      • Ich lasse mir die Sourcemember in der Objekttabelle anzeigen.
        (Wir arbeiten bei uns praktisch immer mit der Objekttabelle und fast nie mit der Sicht "Ferne Systeme")
      • Dann klicke ich mit der rechten Maustaste auf den zu debuggenden Sourcemember (in der Objekttabelle). Siehe Screenshot.
      • Click image for larger version. 

Name:	Rechte Maustaste auf der Objekttabelle.JPG 
Views:	25 
Size:	168,4 KB 
ID:	488
      • Danach komme ich in die Maske, wo ich den Serviceeingangspunkt genauer beschreibe (Programm oder Serviceprogramm, Bibliothek usw.).
      • Falls ich der erste an dem Tag bin, der das Debugging benutzt, kommt danach eine Meldung, ob die Debugserver gestartet werden sollen. Siehe Screenshot:
      • Click image for larger version. 

Name:	Sollen die Debugserver gestartet werden.JPG 
Views:	11 
Size:	38,0 KB 
ID:	489
      • Wenn ich das mit Ja bestätige, dauert es vieleicht ein, zwei Sekunden. Dann ist der SEP gesetzt und ich kann die Anwendung aufrufen. Ein manuelles Starten oder Stoppen der Debug Server ist bei uns nicht erforderlich.
      • Wenn sich dein RDi "weghängt": Gibt es vielleicht eine SYSOPR Meldung?


    Dieter
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken Click image for larger version. 

Name:	Sollen die Debugserver gestartet werden.PNG 
Views:	12 
Size:	22,2 KB 
ID:	490  


  3. #3
    Registriert seit
    Oct 2014
    Beiträge
    28
    Hallo @dschroeder!

    Zu dem Punkt mit der Meldung in
    SYSOPR: Werde ich morgen gleich mal testen!

    Du hast geschrieben, dass Du meine Ausführung nicht (ganz) verstanden hast. Könntest Du auflisten, was ich nicht ganz erklärt habe?

    Lg

  4. #4
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    • Was ist RDI 9.0.3.6 ? (Ich habe 9.6.0.4)


    Was meinst du mit:
    2.) Subsystem "Objekte" -> Befehl eingeben -> "STRDBGSVR" als "Normal"
    Ich muss da nie etwas machen. (Objekte -> Befehl eingeben habe ich noch nie benutzt, glaube ich.)

    Du hast da einfach sehr viel beschrieben, was du alles ausprobiert hast. Hast du das Problem jetzt nur im RDi oder kannst du auch im Green Screen nicht debuggen? (Im Green Screen muss man nochmal unterscheiden zwischen interaktivem Debug und STRSRVJOB für das Debuggen fremder Jobs). Was geht denn bei dir und was nicht?

  5. #5
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Übrigens läuft Debug Dämon standardmäßig auf Port 8001. Ist der Port bei euch vielleicht durch eine Firewall blockiert? Du kannst den Port unter Fenster / Benutzervorgaben einstellen:Click image for larger version. 

Name:	Benutervorgaben.PNG 
Views:	13 
Size:	48,2 KB 
ID:	491

  6. #6
    Registriert seit
    Oct 2014
    Beiträge
    28
    Ok das mit der Version tut mir leider, meinte natürlich 9.6.0.3. Hab mich da in der Reihenfolge vertan *augenroll*

    Zu dem "STRDBGSVR" als "Normal": Wenn ich auf das Befehl eingeben klicke, erscheint ein Dialog mit einer Eingabezeile, einem Button und 3 RadioButtons, mit denen ich steuere, ob ich den Befehl direkt (also Normal), im Staple (also mit SubmitJob) oder noch was (fällt mir jetzt grad nicht ein, was die dritte Option ist) ausführen will.

    Das Problem, dass sich das Fenster aufhängt, also der Task nicht mehr antwortet hab ich bei RDI. Im GreenScreen kann ich das Fenster an sich schon noch herum bewegen, nur nimmt mir die Sitzung keine Eingaben mehr an.

    Edit: Ich hab jetzt mal sowol im Green Screen, als auch im RDI den Debug Server nach den oben beschriebenen Methoden gestartet. Habe keine Meldung in der MSGQ vom QSYSOPR gefunden (hab sie auch mal geleert, auch nix)

    Lg

  7. #7
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    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).

  8. #8
    Registriert seit
    Oct 2014
    Beiträge
    28
    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

  9. #9
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    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?

  10. #10
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    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.

  11. #11
    Registriert seit
    Oct 2014
    Beiträge
    28
    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.

  12. #12
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    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.

Similar Threads

  1. Remote Debugging unter Verwendung von RDI 9.6.0.3 funktioniert nicht
    By LasterOfDesaster in forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 04-06-18, 09:59
  2. Performance einer Java-Anwendung
    By SourceCoder in forum NEWSboard Java
    Antworten: 4
    Letzter Beitrag: 04-07-14, 11:27
  3. Antworten: 14
    Letzter Beitrag: 25-12-13, 17:41
  4. STRPCCMD blockiert Anwendung
    By peter-venkman in forum IBM i Hauptforum
    Antworten: 2
    Letzter Beitrag: 09-07-02, 09:55
  5. XML-Anwendung
    By Case Consult in forum Archiv NEWSboard Events
    Antworten: 0
    Letzter Beitrag: 18-03-02, 12:41

Tags for this Thread

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •