Job Informationen lesen

[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.

[Fuerchau]

Da du im WRKJOB ja eine Kommandozeile hast, die Jobinformation oben angezeigt wird kannst du den STRSRVJOB doch einfach mit den Informationen ergänzen.

Das Problem mit diesen ganzen Serverjobs ist eben, dass der Jobname den initiierenden User (halt QUSER) beinhaltet. Durch die API's QSYSETPH kann ich dann unter einem anderen User arbeiten was allerdings den Jobnamen nicht ändert.
Die IBM müsste ja sonst jedes mal einen neuen Job mit dem Usernamen initiieren.
Größtenteils ist dies nicht möglich, da bestimmte Ressourcen eben nicht von einem Job zum nächsten übergebbar sind.

[svit]

mein ziel war strsrvjob zu automatisieren.
zum Bsp. durch Command srv - (es werden die Job informationen ausgelesen und dadurch strsrvjob vervollständigt.)
na ja, habe verstanden, es geht nicht #)

[Fuerchau]

Geht nicht gibt's nicht.
Es hindert dich niemand, ein eigenes WRKSRVJOB zu entwickeln, dass die Jobs per Job-API auflistet und eine Auswahl 1 anbietet, die Auswahl 5 wäre auch sinnvoll.