QSQSRVR Jobs

[samik]

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]

Such mal hier im Forum nach QSQSRVR.

Gruß
Bruno

[samik]

Danke dir Bruno,

aber es gibt nur mich mit dieser Frage

Such mal hier im Forum nach QSQSRVR.

Gruß
Bruno

[Bruno Jakob]

Seltsam, die Suchfunktion hier. Versuch mal den Link:

http://www.rlpforen.de/showthread.php?t=4554

Gruß
Bruno

[Bruno Jakob]

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.

[BenderD]

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

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

[Fuerchau]

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) ?

[BenderD]

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) ?

[samik]

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

[BenderD]

Hallo,

ich würde den MONMSG CPF0000 auf MONMSG CPF9999 ändern, dann steht die letzte Meldung mit im Joblog. Ansonsten ist es sowieso eine gute Idee, alles was bei der Sicherung der QUSRSYS nicht geht zu ignorieren, das darf eh' nicht restored werden und da kommen und gehen die Probleme mit jedem Cum Stand.

mfg

Dieter Bender

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

[samik]

Dieter, danke für den Tip, ich werde das Programm so ändern.

mfg
Samik