Save Spoolfiledata ???

[dabeda]

Hallo Forum!

Hatte gestern einige Probleme beim Sichern von Spoolfiles. Hab ein Programm zum Archivieren von OutQs geschrieben dass das neue SPLFDTA (*ALL) unter V5R4 benutzt und habe dabei folgendes Problem gehabt.
Testweise wollte ich die QEZJOBLOG mit 22320 Spools sichern, aber nach einiger Zeit wurde die Maschine extrem langsam, User flogen raus, Programme stürzten ab usw. In QSYSOPR wurde gemeldet dass mein Job bereits über 30.000(!) Locks hält, die aber mit einem DSPJOB nicht zu sehen waren.
Es half nur mehr ein ENDJOB (*IMMED) damit der normale Betrieb wieder hergestellt werden konnte. Was bitte wird da gelockt?? Kann ich das irgendwie umgehen oder ist es einfach nicht möglich so viele Spools im laufenden Betrieb zu sichern?

MfG Peter

[cbe]

Hallo,

habe es noch nie probiert, aber vielleicht hilft SAVACT(*SYNCLIB)?

Gruß,
Christian

[dabeda]

Danke für die schnelle Antwort!

Hm, das könnte möglich sein, werde es probieren wenn nicht viel los ist am System, traue mich das nicht mehr im Vollbetrieb.

MfG Peter

[Fuerchau]

Das kann auch nicht im Vollbetrieb laufen. Am Besten ist sogar, das Spoolsystem zu beenden.
*SYNCLIB hilft da ggf. auch nicht, da die gesamte Lib gegen Veränderung gesperrt werden muss.

Da es keine eindeutige Zuordnung eines Spools (Name/Job) zu einer bestimmten Datei in QSPL gibt, kann man nicht mit Bestimmtheit sagen, dass nur bestimmte Dateien gesperrt werden.

Wenn eine Datei wegen Sicherung gesperrt ist, kann keine neue Teildatei hinzugefügt werden, was bei Spoolerstellung aber unweigerlich passiert.

[dabeda]

Ja das klingt einleuchtend.
Habs mit kleineren OutQs probiert, da funktionierts einwandfrei. Wollte halt dass dieses Programm generell fehlerfrei läuft ohne dass man darauf aufpassen muß wie groß die OutQ ist.
Wird also ein Nachtjob werden ...

Vielen Dank für die Info!

MfG Peter

[holgerscherer]

Testweise wollte ich die QEZJOBLOG mit 22320 Spools sichern,

Grade die QEZJOBLOg ist für solch einen Test genau das Richtige ;-) Da kommen ja ständig neue Spools dazu, je nach Einstellung der JOBDs. Und beim Sichern (Spools sind mehr oder weniger auch nur PFs mit Members) diese irgendwie gelockt werden, kann kein Joblog geschrieben werden. Probier das parallel mal mit einer OutQ, die keiner benutzt (aber viele Spools hat) und erstelle während dem Sichern dort ein Spool - geht gern in die Hose.

IBMs Denke bei der Erstellung der Parameter zum Sichern von Spools war wohl: Damits beim SAVE21 geht...

-h

[Fuerchau]

Naja, Spools sind halt auch nur DB-Objekte und beim Sichern von Anwendungs-Lib's wird diese ja auch häufig beendet, da SAVACT nicht immer wie erwartet funktioniert und ggf. zu Inkonsistenz führt.

[dabeda]

Da es keine eindeutige Zuordnung eines Spools (Name/Job) zu einer bestimmten Datei in QSPL gibt, kann man nicht mit Bestimmtheit sagen, dass nur bestimmte Dateien gesperrt werden.

Also wenn ich das richtig verstanden habe, dann ist es egal welche OutQ ich sichere, es kommt dann einfach aufs Glück an ob wichtige Dateien gesperrt werden und dadurch die Sicherung in die Hose geht, oder?

Probier das parallel mal mit einer OutQ, die keiner benutzt (aber viele Spools hat) und erstelle während dem Sichern dort ein Spool - geht gern in die Hose.

Ganz schön kompliziert ...

[Fuerchau]

Schau dir einfach mal mit WRKOBJPDM die QSPL an.
Es gibt keine Definition, welcher Spool in welcher datei/Teildatei landet, das System verwaltet das selber.

Da Spools ja auf beliebige OUTQ's verschoben werden können, ändert sich der Speicherort jedoch nicht.

Da der SAV jedoch einfach die Datei/Teildatei des Spools sperrt und dies ggf. sämtliche Dateien sein können, kann eben während dessen kein neuer Spool erstellt werden.

[dabeda]

Ja jetzt hab ichs verstanden. Klingt eigentlich ganz logisch wenn man es weiß.

Vielen Dank nochmal!