QZDASOINIT Jobs Detailinformationen

[hteufl]

Hallo,

wir haben QZDASOINIT Jobs die Datenbankdateien sperren und die Datensicherung verzögern! Da sehr viele Fremdprogramme auf das ERP per ODBC oder MS-SQL zugreifen würde es sehr hilfreich sein, wenn man die IP Adresse des Sperrusers feststellen könnte. Die Jobnummer alleine hilft uns nicht weiter da bei einem QZDASOINIT Eintrag mehrer Einträge mit Benutzer QUSER vorhanden sind. Ausserdem ist die LOGDatei (QHST) auch nicht sehr Informationsreich.
Oder gibt es eine detailliertere Ausgabe zu den QZDASOINIT Jobs?
Hier ein kleiner Auszug aus WRKOBJLCK:

QZDASOINIT QUSER 646305 *SHRRD HELD *JOB
QZDASOINIT QUSER 646328 *SHRRD HELD *JOB
*SHRRD HELD *JOB
*SHRRD HELD *JOB
QZDASOINIT QUSER 646377 *SHRRD HELD *JOB
*SHRRD HELD *JOB
*SHRRD HELD *JOB
QZDASOINIT QUSER 646490 *SHRRD HELD *JOB
QZDASOINIT QUSER 646555 *SHRRD HELD *JOB


Vielen Dank im Voraus

Hermann TEUFl

[Dschainers]

Im Joblog steht die IP-Adresse

[Andreas_Prouza]

Es gibt auch mit die SQL Views NETSTAT_INFO & NETSTAT_JOB_INFO.
Dort kannst du die entsprechenden Infos ermitteln.
Es gibt auch die View QSYS2.OBJECT_LOCK_INFO um die Jobs mit den gesperrten Objekten zu finden.

lg Andreas

[RobertMack]

Sprich mal mit den ERP Leuten. Meist sind das lauschende oder Daten tauschende Verbindungen mit einem eigenen Wiederanlauf.

Falls sich das bestätigt, kannst Du vor Deiner Sicherung einen ENDSBS QUSRWRK (*IMMED oder *CNTRLD mit n Sekunden) absetzen und danach das Subsystem mit STRSBS QUSRWRK wieder starten.

[hteufl]

Vielen Dank für die Antworten!

Die SQL Abfrage von QSYS2.OBJECT_LOCK_INFO schaut vielversprechend aus. Werde mal versuchen den Täter(n) auf die Spur zu kommen.
Vielen Dank für Eure Unterstützung

Hermann TEUFL

[Fuerchau]

Ich würde da pragmatisch vorgehen. Wenn es heißt, zu bestimmten Zeiten stehen bestimmte Dienste nicht zur Verfügung, dann werden die Dienste einfach beendet.
QUSRWRK würde ich nicht beenden, da auch andere Jobs dort laufen.
U.U. greife ich mit einem Java-Job lokal zu, das läuft auch über QZDASOINIT.

Hier reicht eher ein ENDHOSTSVR, der auch die offenen Verbindungen killt.

[Andreas_Prouza]

Ich würde auch alle geschäftskritischen JDBC Verbindungen in ein eigenes SBS umleiten.
Das kann dann nach belieben gestartet und beendet werden ohne dass andere (vielleicht wichtige) Verbindungen ebenfalls gleich beendet werden.

[hteufl]

Vielen Dank für die Inputs!

Welcher HOSTSVR wäre zu beenden um die aktiven QZDASOINIT Jobs zu beenden? Ich denke man kann den Softwareherstellern kommunizieren, dass zur Backupzeit kein Zugriff auf das System erlaubt ist.
Die Auswertung der QSYS2/OBJ_LOCK Datei hat auch kein vernünftiges Ergebnis gebracht. Hier stehen nur 2 Programme in der Auswertung (QDMCOPEN und QQQOOODBOP) mit dem Benutzer QUSER. Von dem her würde ich auch die Variante mit ENDHOSTSVR bevorzugen, damit alle nicht korrekt geschlossenen Verbindungen gekillt werden.

Vielen Dank im Voraus und lg
Hermann

[Fuerchau]

*DATABASE wäre der Service.