Job Informationen lesen

[svit]

Hallo *all,
Ausgangssituation 1:
Befehlszeile - wrkusrjob - Es werden alle Jobs des Users angezeigt.
An dieser Stelle gibs es nur Auswahl 4, 5 und 8.

Besteht hier die Möglichkeit eine neue Auswahl zu erstellen
zum bsp. "strsrvjob" und anschliessend strdbg mit Programmeingabe.

Ausgangssituation 2:
Befehlszeile - wrkusrjob -Auswahl 5 vor einem Job-> man verzweigt in das Fenster "Mit Job Arbeiten" .

Besteht die Möglichkeit Informationen wie JOB/Benutzer/Nummer auszulesen.

[dschroeder]

Ich glaube nicht, dass man die Auswahlen dort ergänzen kann. Aber ich denke, dein Problem ist, dass du einen Job eines Users debuggen möchtest (per strsrvjob)? Ich habe das bei mir folgendermaßen gelöst: Ich rufe die Jobanzeige mit der Auswahl 5 auf. Dann starte ich ein Makro, dass ich mit der Client Access Makrofunktion per "Makro aufzeichnen" erstellt habe. Dieses Makro liest die Jobinformationen, die ja immer oben an den gleichen Positionen stehen und erzeugt auf der Befehlseingabezeile einen String, in dem das strsrvjob-Kommando passend zusammengebaut ist.

Dieter

[dschroeder]

Noch ein Hinweis: In Client Access kann man Makros ja einfach auf die rechte Maustaste legen. Du könntest natürlich mehrere Makros für unterschiedliche Zwecke aufzeichnen und im Kontextmenü (IBM nennt das "Dialogfenstertastenblock") anzeigen.

Dieter

[Fuerchau]

Das geht auch einfacher:
strsvrjob jobname
Bei mehreren Jobs wird eine Liste angezeigt, den richtigen mit 1 auswählen und fertig ist man.

[dschroeder]

Aber dann muss man den Jobnamen kennen. Bei interaktiven Sitzungen ist das ja oft ein generierter Name (QPADEVxxxx). Da ist ein wrkusrjob <username> oft einfacher.

Aber grundsätzlich finde ich den Tipp mit dem strsrvjob <jobname> prima. Kannte ich bisher noch nicht.

Dieter

[Fuerchau]

Selbst dann weiß ich doch welchen QPADEVxxx ich observieren will.
Es ist halt nur mühsam, den Jobnamen immer abzutippen, da die Anzeige mit dem CMD-Parameter nie übereinstimmt.

Im übrigen weiß ich nicht, warum noch mit QPADEV (o.ä.) gearbeitet wird.
Inzwischen lassen sich alle Emulationen mit richtigen Namen versehen.
Ins besonders bei Journlisierungen (oder eigenen Protokollen) ist die Nachvollziehbarkeit besser gewährleistet und der Wiederanlauf (DEVRCYACN(*DSCMSG)) gestaltet sich auch besser.

[svit]

wenn mehrer Jobs zum bsp. über webservice, oder ... gestartet werden dann laufen alle in die QUSRWRK und heissen alle QZRCSRVS und User Quser. Natürlich mit dem Befehl wrkusrjob können alle jobs die ein Bestimmrer Benutzer gestarte aufrufen. Und dann immer wieder tippen, tippen ... scheisse.
(wer ist dieser IBM eine 3 Man Firma, oder wird einiges hobbymässig entwickelt)
Uncool ist das man ständig irgendwelche krücken bauen muss.
Danke trotzdem.

[Fuerchau]

Nunja, da hilft ein wenig der iSeries Navigator.
Hier wird bei diesen Jobs (wie bei QZDA-Jobs auch) der tatsächliche User angezeigt.
Dann kann man ja dann die Job-Nr. erfahren um die es geht.

[svit]

wenn man weis wer den Job abgesetzt hat, und gibt den Namen im wrkusrjob werden alle QUSER- Jobs von dem user angezeigt.
Cool wäre, wen überall die benutzerdefinierte Auswahlmöglichkeiten zur verfügung stehen wurden (wie im PDM)

[dschroeder]

wenn mehrer Jobs zum bsp. über webservice, oder ... gestartet werden dann laufen alle in die QUSRWRK und heissen alle QZRCSRVS und User Quser.

Wenn die QZDASOINIT oder QZRCSRVC für einen bestimmten User laufen (eben weil sie z.B. die SQL-Anfrage eines Users bedienen), kann man sie folgendermaßen eingrenzen:
wrkobjlck <user> *usrprf

Zur Klarstellung: Die Jobs laufen zwar unter QUSER, sind aber dem Benutzerprofil des "echten" Benutzers zugeordnet. Das kann man mit wrkobjlck herausfinden.

Dieter

[dschroeder]

Noch ein Tipp: Du kannst natürlich auch einfach einen Service Entry Point setzen (mittels Debug). Dort kannst du ja den "richtigen" Userprofilnamen als Selektion angeben. Dann läuft der Debug genau in den Job rein, den der betreffende User initiiert. Da musst du den Job überhaupt nicht manuell identifizieren.
Falls du RDi einsetzt, kannst du den Service Entry Point ja sogar sehr komfortabel über eine grafische Oberfläche setzen.

Das geht natürlich nur, wenn es in dem Job auch ein debugbares Programm gibt.

Dieter

[svit]

genau
ob mit wrkobjlck oder wrkusrjob egal. Das Hauptproblem wird dadurch nicht kleiner.