View Full Version : QSQSRVR Jobs
Hallo!
Welche Funktion haben QSQSRVR Jobs in QSYSWRK?
Wir sichern im aktiven Zustand und manchmal bricht die Sicherung ab: CPI8365 - COMMIT- oder ROLLBACK-Operation für Job .../QUSER/QSQSRVR zum Sichern im aktiven Zustand erforderlich.
Wir haben schon SAVLIB und SAVOBJ Befehle verändert und SAVACTWAIT auf 20sek. gesetzt.
Mit den anderen Libs. gibt es keine Probleme. Wenn ein Objekt mehr als 20sek gesperrt ist, wird es nicht gesichert und die Sicherung läuft weiter. Aber wenn QUSRSYS gesichert werden muss, dann sieht es so aus, dass COMMIT & ROLLBACK- Anforderung den SAVACTWAIT Parameter gar nicht interessiert :-)
Ich danke allen im voraus für eine Antwort!
Samik
Bruno Jakob
04-11-04, 12:36
Such mal hier im Forum nach QSQSRVR.
Gruß
Bruno
Danke dir Bruno,
aber es gibt nur mich mit dieser Frage :rolleyes:
Such mal hier im Forum nach QSQSRVR.
Gruß
Bruno
Bruno Jakob
04-11-04, 12:59
Seltsam, die Suchfunktion hier. Versuch mal den Link:
http://www.rlpforen.de/showthread.php?t=4554
Gruß
Bruno
Bruno Jakob
04-11-04, 13:05
Ach ja, das sagt die IBM dazu:
QSQSRVR jobs: Perform Call Level Interface DB2 UDB SQL functions used by IBM functions such as Management Central and typically by Java-based applications performing SQL. These jobs or threads default to running at priority value 10.
Hallo Samik,
das sind Database Server Jobs, aber mit der QUSRSYS sollten die eigentlich nix machen und offene Commit Gruppen sollten die dann erst recht nicht haben. Da treibt irgendein Job Dummfug der dummfugigsten Sorte und sollte es ein Systemjob sein (wg. QUSRSYS) dann ist da ein Bug, apropos Bug, habt ihr WebsFear auf der Kiste aktiv???.
mfg
Dieter Bender
Hallo!
Welche Funktion haben QSQSRVR Jobs in QSYSWRK?
Wir sichern im aktiven Zustand und manchmal bricht die Sicherung ab: CPI8365 - COMMIT- oder ROLLBACK-Operation für Job .../QUSER/QSQSRVR zum Sichern im aktiven Zustand erforderlich.
Wir haben schon SAVLIB und SAVOBJ Befehle verändert und SAVACTWAIT auf 20sek. gesetzt.
Mit den anderen Libs. gibt es keine Probleme. Wenn ein Objekt mehr als 20sek gesperrt ist, wird es nicht gesichert und die Sicherung läuft weiter. Aber wenn QUSRSYS gesichert werden muss, dann sieht es so aus, dass COMMIT & ROLLBACK- Anforderung den SAVACTWAIT Parameter gar nicht interessiert :-)
Ich danke allen im voraus für eine Antwort!
Samik
Danke Bruno,
ich habe die Infos gelesen, vielen Dank.
Sie können natürlich alle laufen, aber was mache ich mit den Jobs, die meine Sicherung zum Abbruch bringen? Im Sicherungsjob alle bekannten Msg abfangen?
Komisch, bei mir bricht eine Datensicherung nicht ab, wenn DB-Dateien im Zugriff sind, da für diese ein temporärer Bereich angelegt wird.
Anders siehts tatsächlich mit Journalen aus, wenn ein Commit-Zyklus über die SAVACTWAIT-Zeit hinaus dauert. Dann geht der Save dafür nicht.
Offene Commit-Zyklen über 20 Sekunden sollten eigentlich nicht vorkommen !!!
Welche Objekte genau sind denn da im Zugriff bzw. werden nicht gesichert ?
Gibt es ODBC-Anwendungen, die ggf. dauernd neue Tabellen anlegen, löschen und das ganze noch journalisiert (wobei das nicht die QUSRSYS betrifft) ?
Hallo,
ich denke Benutzerjobs scheiden eigentlich aus.
Ich tippe eher auf:
- stecken gebliebene Adminkonsole von WebsFear
- stecken gebliebener Ooops Nerv
- stecken gebliebener Management Central
oder irgendwas von dieser "Qualität".
Diesen dreien und Lokus Notes traue ich jedenfalls auch Stunden lange Commit Zyklen zu.
Was macht denn eigentlich der Sicherungsjob da genau? Bleibt der stehen und wartet sich tot? oder bröselt er runter, das könnte man ja fangen.
mfg
Dieter Bender
Komisch, bei mir bricht eine Datensicherung nicht ab, wenn DB-Dateien im Zugriff sind, da für diese ein temporärer Bereich angelegt wird.
Anders siehts tatsächlich mit Journalen aus, wenn ein Commit-Zyklus über die SAVACTWAIT-Zeit hinaus dauert. Dann geht der Save dafür nicht.
Offene Commit-Zyklen über 20 Sekunden sollten eigentlich nicht vorkommen !!!
Welche Objekte genau sind denn da im Zugriff bzw. werden nicht gesichert ?
Gibt es ODBC-Anwendungen, die ggf. dauernd neue Tabellen anlegen, löschen und das ganze noch journalisiert (wobei das nicht die QUSRSYS betrifft) ?
Hallo Dieter,
danke für die Antwort.
Die Fehlermeldungen werden mit MONMSG CPF0000 abgefangen, deshalb bleibt der Job nicht hängen.
Heute lassen wir die Sicherung ohne MONMSG laufen, dann haben wir bestimmt mehr Infos.
MfG
Samik