Save while active mit BRMS

[systemer]

Hallo *all,

wir sichern unsere R/3-Lib mittels BRMS während das System aktiv ist. Ab und zu bricht die Sicherung ab, weil ein Objekt z.B. für 3 Minuten unter excl. COMMIT-Kontrolle ist, während der Save dieses Objekt für die Sicherungskonsistenz markieren will, aber nicht darf. Nach 2 Minuten (Default Zeit) bricht die Sicherung ab.

Ohne BRMS würde ich im SAVLIB-Befehl den Param. SAVACTWAIT=nnn nutzen, um die Zeit, die der Save auf das Ende eines COMMITs wartet, zu verlängern.

Meine Frage ist nun:
Wie kann ich unter BRMS diese Wartezeit einstellen? Ich vermute, BRMS nutzt den Befehl SAVLIBBRM, der aber den Param. SAVACTWAIT nicht enthält. Im BRMS selbst bzw. in der CTLGRP habe ich auch noch keine Möglichkeit entdeckt.

Hat irgend jemand "draussen" noch einen Tip??
Für jede Hilfe bin ich dankbar.

Gruß,
Franz

[Fuerchau]

Sie können die Defaultzeit des/der entsprechenden SAV-Kommandos mittels CHGCMD ändern, so dass diese Zeit für BRMS gilt.

Anmerkung: Bei einem Releasewechsel müssen sie die Änderungen der CMD's allerdings wiederholen.

[systemer]

Ich sehe da einiges an REXX- und Programm-Parametern, die geändert werden können. Leider ist mir dieses Funktionsspektrum der iSeries nicht geläufig (wir nutzen die Maschine ausschließlich als R/3-Server, mit Programmierung und Prozeduren haben wir nur am Rande zu tun). Ist es arg umständlich zu erklären, was im CHGCMD zu ändern wäre?

[MBH]

Hallo Franz,

wenn ich die BRMS Hilfe richtig verstehe könnte man noch in den Systemsteuerangaben bei 'Objektvorprüfung' ein *no eingeben. Dann allerdings wird dieses Objekt nicht mitgesichert.

Gruß
Markus

p.s.: wir haben auch vor kurzem auf save while active umgestellt. Bricht zwar nicht ab (wir haben Objektvorprüfung *no) hat aber deutlich erhöhte Laufzeit.

[Heinz Bretthauer]

Hallo Franz,

der Standard des SAVLIB Befehls läßt sich mit

CHGCMDDFT CMD(SAVLIB)
NEWDFT('SAVACTWAIT(180)')

verändern. In diesem Fall wären es dann 180 Sekunden.

Viele Grüße
Heinz

[systemer]

Hallo Markus,

geht leider nicht; wenn auch nur 1 Objekt in der Sicherung fehlt, ist im R/3 ganz schnell der Teufel los - leider...

Gruß,
Franz

[systemer]

Hallo Heinz,

habe von anderer Stelle einen Hinweis erhalten, dass BRMS evtl. doch nicht den SAVLIBBRM-Befehl sondern den Standard-SAVLIB Befehl. Werde es mal mit dem CHange-Befehl versuchen und das Sicherungsverhalten beobachten.

An dieser Stelle danke an alle, die geantwortet haben.

Gruß,
Franz

[homerun]

Hallo
Wir sichern auch mit BRMS und ich hatte vor einigen Tagen auch das Problem ich auch vergeblich in BRMS gesucht aber nichts gefunden ,bzw. hab mir in der Steuergruppe mal die Parameter (Sichern im aktiven Zustand an) da funktioniert nur F1 nicht wie gewohnt F4 . ich habe den Parameter von *yes auf *lib gesetzt der Fehler ist bis jetzt nicht mehr aufgetaucht kann aber nicht sagen ob es daran gelegen hat. Das Problem hatte ich auch erst 2 mal . Vielleicht hilft es ja .

[systemer]

Hallo Homerun,

wie ich die Hilfe im BRMS verstehe, bedeutet in der CTLGRP der Param. *YES, daß DLOs während des Sicherns geändert werden können. Nicht DLO-Objekte (zB. Libs) werden so behandelt als wäre *LIB angegeben.

Der Param. *LIB bezieht sich wohl ausschließlich auf die Bibliothekssicherung.

Habe, wie gesagt, von anderer Seite den Hinweis erhalten, daß wohl doch generell der Befehl SAVLIB in QSYS benutzt wird (WRKOBJ SAVLIBBRM -> Opt. 8 zeigt die letzte Verwendung des Objekts an; und SAVLIBBRM wurde demnach schon seit über einem Jahr nicht mehr verwendet). Darum habe ich den Param. SAVACTWAIT testweise auf 3600 gesetzt. Wozu es dann den Befehl SAVLIBBRM überhaupt gibt, bleibt mir weiterhin rätselhaft.

Gruß,
Franz

[Fuerchau]

Dazu noch eine Erklärung:
Sichern im aktiven Zustand bedeutet NICHT, dass Objekte nicht gesichert werden.
Für Datenobjekte wird ein Synchronisationspunkt gesetzt, ab dem alle Änderungen in einem temporären Bereich durchgeführt werden, während die Sicherung läuft.
Nach der Sicherung werden diese temporären Änderungen in die Datenobjekte übernommen.
Leider funktioniert das nicht für alle Objekte (z.B. DTAARA's).
Ist die Zeit also sehr hoch (wie hier 3600) wird auf jedes Objekt 1 Stunde gewartet bevor der Synchronisationspunkt ermittelt wird. Die Wartezeit ist hier kumulativ zu sehen, d.h., wenn auf 5 Objekte gewartet werden muss, wartet der SAV 5 Stunden bevor er überhaupt anfängt zu sichern !!!

Ich habe gute Erfahrungen mit 0 (Null Sekunden) gemacht. Soweit es reine Dateien angeht stellt das kein Problem dar.
Bei Objekten wie DTAARA hilft fast kein Wert, da nach Ablauf dieser Zeit das Objekt tatsächlich nicht gesichert wird !

Ich habe leider nichts gefunden, welche Objektarten beim "Sichern im aktiven Zustand" nicht synchronisiert werden können (DTAARA's habe ich auch nur durch Zufall erfahren).

[homerun]

Hallo
Also ich muß zugeben das ich den ganzen Sinn noch nicht so richtig verstanden hab. Sichern im Aktiven Zustand bedeutet für (mich) ich sicher ein objekt oder lib auf Band oder sonst wie obwohl es in Benutzung ist . Demnach verstehe ich den Parameter SAVACTWAIT überhaupt nicht meiner Meinung nach dürfte der ja gar nicht auftauchen . Denn dies bedeutet ja dann wenn ein Job in der angegebenen Zeit das objekt nicht freigibt wird es nicht gesichert richtig ? @Fuerchau hat schon recht mit seinen 5 Stunden wenn um 07:00 Uhr erst 60 MB von meheren Gigs gesichert worden sind hat man keine Sicherung vom Vortag . Gibt es denn da keine Möglichkeit außer endsbs *all *immed zu sagen sicher mich doch alle objekte die ich gerne hätte ? Die AS/400 bietet soo viele Möglichkeiten und es wird doch nicht an so (KLEINIGKEITEN) haken oder ?
Ich hatte das Problem nämlich heute schon wieder. Da ich aber so flink mit den Tasten war habe ich nicht ins log geschaut welches Objekt denn da gelockt war. Vielleicht liegt das Problem ja bei unseren Jobs . Werde da aber nochmal genauer nachschauen.

[homerun]

Hallo nochmal
Ich hab nochmal das log überflogen ich habe die MSG CPF377F bekommen kurz vor ende der Sicherung . Als Bibliothek wurde die QUSRSYS angegeben was ich auch wieder nicht verstehe morgen so dann so .Also so wies aussieht keine Jobs von uns.