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.