Save while active mit BRMS

[Fuerchau]

Also bei der Sicherung sollte man sich genau überlegen, welche Bibliotheken zu sichern sind.
In der QUSRSYS werden normalerweise nur OUTQ's abgestellt, der Rest sind wiederung Systemobjekte. OUTQ's können nicht gesichert werden (ausser als Objekt selbst), da sie nur Spools verwalten.
Remote-Outq's verwalten halt nur Spools von Netzdruckern. Die Spools selbst (QSPL) kann sowieso nicht gesichert werden.
Da diese Outq's nun mal durch Spool-Jobs belegt sind, können diese halt nicht gesichert werden ausser man beendet mit ENDWTR *ALL und ENDSBS QSPL.
QUSRSYS sollte also nur gesichert werden (wenn überhaupt), wenn in den USER-Objekten gravierende Änderungen stattfinden.
Das gilt nun mal leider auch für QGPL. Wenn man mit Netzverteilungen (SND-Befehle) arbeitet, sind alle dazu benötigten Einträge in den QAO*-Dateien zu finden. Wenn als QSNADS aktiv ist, gibts auch Probleme beim Sichern von QGPL.

Also was soll man sichern ?

Bei der täglichen Sicherung sollte man AUSSCHLIEßLICH Anwendungs-DATEN-Bibliotheken und bestimmte IFS-System sichern.
Programm-Bibliotheken, die sich eigentlich nicht ständig ändern, sollten einmalig nach jeder Änderung separat gesichert werden (also nicht in der täglichen).
Und natürlich das System incl. Lic-Pgm's nach jedem PTF-Update.

Nun noch mal zum "Sichern im aktiven Zustand" !

Hierzu gibt das Handbuch "Work-Management-Guide" eigentlich sehr gute Auskunft
(Siehe meine Beschreibung oben).
Durch die Definition des Synchronisationspunktes (*LIB, ...) werden alle sog. Datenobjekte (im wesentlichen PF's, LF's) sozusagen gleichzeitig gegen Änderungen gesperrt. Damit die Anwendungen nix merken, werden Lesezugriffe erlaubt, Schreibzugriffe aber in einem temporären Bereich durchgeführt solange die Sicherung läuft. Sobald die Sicherung die Sperren aufhebt, werden die Änderungen aus den temporären Bereichen in die Original-Objekte übertragen und die Objekte tatsächlich freigegeben.

Warum also eine Wartezeit definieren ?
Das kann ich auch nicht beantworten, wie oben gesagt, mit einer Zeit von 0 Sekunden sichert man sehr schnell ohne auf das Freiwerden von Objekten warten zu müssen.
Datenobjekte werden auf jeden Fall korrekt gesichert. Im Joblog findet man genau, welche Objekte nicht gesichert wurden. Und das sind genau die, die auch bei langer Wartezeit (solange halt die belegenden Jobs aktiv sind) nie gesichert werden.

Besonders ist noch zu beachten, wenn man mit Journalisierung fährt. Soweit ich mich erinnere, werden Journale NIE gesichert, wenn noch offene Commit's aktiv sind. Bei einer normalen Applikation (insbesonders bei Batchverbuchern wie bei SAP) ist ständig ein Commit geöffnet, denn jeder Commit/Rollback eröffnet ein neues Commit. Erst wenn der Job beendet wird bzw. ENDCMTCTL ausgeführt ist, wird das Journal von diesem Job freigegeben.
Deswegen muss man hier bei der Datensicherung besonderes Augenmerk auf die Planung werfen, z.B.: 1x die Woche Datensicherung der kompletten Datenbank, täglich oder häufiger die Sicherung der Journale.

Dies kann man, wenn man genug Platz hat, auch mit manuellen SAV-Befehlen in eine SAVF testen oder auch halt auf Band wenn man genug Zeit hat.

Viel Spaß beim ausprobieren.

[systemer]

Auch wenn ich nicht so tief in der Materie bin, möchte ich zu dem Thema nochmal meine Gedanken anbringen.

Laut der Parameterbeschreibung des SAVLIB-Befehls versucht das System inerhalb einer bestimmten Zeitspanne, alle zu sichernden Objekte auf einem gemeinsamen Stand gleichsam „einzufrieren“, um einen definierten Zustand sichern zu können.

Wenn nun ein Objekt durch eine Anwendung in Benutzung ist, kommt die Sicherung – oder besser gesagt die Synchronisationsfunktion – zunächst einmal nicht dran. Es gibt nun zwei Möglichkeiten:
Erstens, das Objekt wird innerhalb der festgelegten Wartezeit von der Anwendung freigegeben, dann kann die Sicherung normal fortfahren.
Zweitens, der Objekt-Lock bleibt während der ganzen Wartezeit bestehen, dann „gibt die Sicherung auf“ und macht beim nächsten Objekt weiter.
Also kann es nach meinem Verständnis doch dazu kommen, daß beim Sichern im aktiven Zustand Objekte nicht gesichert werden.

Noch gravierender sind die Auswirkungen, wenn ein zu sicherndes Objekt gerade in einem Commit-Zyklus gehalten wird. Wenn der Commit-Zyklus innerhalb der festgelegten Wartezeit nicht beendet wird, bricht gleich die gesamte Sicherung ab, so wie es bei homerun passierte und wie es auch bei uns öfter vorkommt! Allerdings muß ich ehrlich sagen, daß mir der Unterschied zwischen einem Objekt in Benutzung und einem Objekt im Commit-Zyklus nicht ganz klar ist – in beiden Fällen handelt es sich doch um eine Konkurrenzsituation zwischen Anwendungsjob und Sicherungsjob, aber OS/400 macht da wohl doch einen Unterschied.

Diese Systemreaktionen vor Augen halte ich es durchaus für sinnvoll, eine Wartezeit vorzugeben. Angenommen, eine der zu sichernden Dateien wird während der Sicherung von einer Anwendung upgedated. Ohne Wartezeit würde das Objekt sofort übergangen bzw. die Sicherung ganz abbrechen. Weiter angenommen, der Update würde lediglich 3 Minuten dauern, dann könnte die Sicherung durch Angabe einer Wartezeit von 5 Minuten „gerettet“ werden.

@Fuerchau: Die Wartezeit ist als KANN-Wert zu sehen. Die Angabe 3600 sagt dem System nur, daß es maximal eine Stunde lang versuchen soll, ein in Benutzung befindliches Objekt zu synchronisieren. Wird das Objekt früher freigegeben, dann läuft die Sicherung auch sofort weiter. Wir hatten genau den Fall letzte Woche: Eine Anwendung hatte eine Datei für 40 Minuten im Commit-Zugriff. Die Sicherung lief genau diese 40 Minuten länger als üblich, obwohl wir die SAVACTWAIT auf 3600 gesetzt haben.

[Fuerchau]

Das mit der Wartezeit ist natürlich korrekt.

Aber nochmal:

Bei meinem Test mit Wartezeit 0, wurden alle Objekte gesichert, für die dieser temporäre Updatebereich verwendet werden kann, auch wenn die Datei zig-Mal geöffnet ist. Es wurde auch kein Objekt ausgelassen, ausser besagter DTAARA.

Mag sein, dass die Wartezeit > 0 dazu führt, dass genau dann nicht gesichert wird, das werde ich nochmal testen.

[homerun]

Hallo nochmal
Wie gesagt das Problem hatte ich heute schon wieder aber ,mal was ganz anderes ? Warum kommt der Fehler denn in der qusrsys es wird "nur" *allusr *savcfg *secdta gesichert warum wird dann die qusrsys mit angepackt ?
Also so wie ich dieses Posting nu verstehe muß man also damit leben ? Aber warum läuft die Sicherung nicht einfach durch sondern bricht ab bzw. steht auf Tapw obwohl da schon lange das commit weg sein sollte. Und manchmal sind commit´s da in der qusrsys und manchmal nicht ob wohl sich im täglichen ablauf NICHTS geändert hat. hatte mich auch schon gewundert das die Sicherungen mal so lange und mal so lange brauchen das hat sich aber soeben aufgeklärt @systemer hat es ja erklärt. Aber was mach ich nun ?
Ich werde mal den dft von savactwait auf 0 setzen schaden kanns ja nu auch nicht mehr ist ja heute schon der 4 Tag gewesen . Mal schaun wie´s nach dem WO ist .

[Bruno Jakob]

Bei *allusr wird die qusrsys mitgesichert. Siehe Hilfetext zu dem Befehl savlib.

Gruß
Bruno

[Sho3]

Hi,

der Job QYPSSRV (Management-Central-Server) sperrt Objekte in der QUSRSYS. Daher sollte man vor der Sicherung den Management-Central-Server beenden. Dann nach der Sicherung kann der MGTC-Server wieder gestartet werden.

Zumindest half dies bei uns.

1.) ENDTCPSVR *MGTC
2.) Save
3.) STRTCPSVR *MGTC

Vielleicht hilfts.

mfg.
Stefan