Objekt Sperren ausfindig machen

[itec01]

Hallo und Guten Morgen,
Seit bei einem Kunden die 3. Schicht eingeführt wurde, hört BRMS einfach bei der Sicherung einer Gruppe (mehrere Bibliotheken in einer Gruppe enthalten) auf. Grund ist, dass BRM keinen Aufsetzspunkt findet (Unable to reach checkpoint CPF377F), weil wohl irgendwelche Objekte, ich vermute Datenbereiche, exclusiv gesperrt sind.
Nun muss ich wissen, welche es sind.
Über den WRKOBJCLK komme ich nicht weiter, weil der mir nur die Jobs gibt, die irgendetwas in der Lib sperren und das muss nicht exclusiv sein. Ebenso kann ich auch nicht bei OBJECT *ALL angeben, was mir geholfen hätte.
Wie kann ich herausfinden welche Objekte dauerhaft gesperrt sind?
Ich vermute, dass man über API's sich behelfen könnte.
Danke schon mal.
Gruß Klaus

[BenderD]

... CPF377F verweist auf offene Commit Definitions. Selbige müsste man mit WRKCMTDFN sehen. Wobei BRMS und Commit ist ein Problem an sich, das kann die BReMSe nicht wirklich.

D*B

[Fuerchau]

Es gibt zwar API's dafür, aber was hilft dir das?
Wenn die tägliche Sicherung erforderlich ist, hilft es nur alle Subsysteme zu beenden, die die Datensicherung behindern könnten. Dazu gehört u.U. auch ein ENDHOSTSVR um ODBC-Zugriffe auszuschließen.
Ansonsten muss man sein Sicherungskonzept der Situation anpassen.

https://www.ibm.com/support/knowledg...s/qwclobjl.htm

[itec01]

Es ist so, dass wir ein 3-stufiges Sicherungskonzept haben. Zu dem Zeitpunkt, wo niemand arbeitet sichern wir die wichtigsten Datenbibliotheken. Danach geben wir das System für die 3. Schicht und für manche Prozesse im Lager frei. Die BRM Problematik taucht bei der Bibliothek auf, wo nur Programmobjekte, Bildschirmdateien und ein paar Datenbereiche liegen.
Commit Definitions können hier nicht vorkommen, weil keine PF Dateien inkludiert sind.
Jetzt habe ich die Möglichekeit die DTAARA's in die erste Sicherung zu packen. Dazu müssen aber dann auch die DTAARA's in die Hauptbibliothek. Das API schaue ich mir an.
Danke.

[Fuerchau]

Datenbereiche gehören i.d.R. auch in eine Datenbibliothek, es sei denn, sie werden nur zum Compilezeitpunkt (für irgendwelche Tools) benötigt.
DSPF's und PRTF's sind zur Laufzeit natürlich gesperrt, unterliegen aber keiner Veränderung.
Und Programmbibliotheken brauchen nur gesichert werden, wenn sich da irgendwas geändert hat und das kann man separat steuern.

[itec01]

Ja, so sehe ich das auch.

[BenderD]

Es ist so, dass wir ein 3-stufiges Sicherungskonzept haben. Zu dem Zeitpunkt, wo niemand arbeitet sichern wir die wichtigsten Datenbibliotheken. Danach geben wir das System für die 3. Schicht und für manche Prozesse im Lager frei. Die BRM Problematik taucht bei der Bibliothek auf, wo nur Programmobjekte, Bildschirmdateien und ein paar Datenbereiche liegen.
Commit Definitions können hier nicht vorkommen, weil keine PF Dateien inkludiert sind.
Jetzt habe ich die Möglichekeit die DTAARA's in die erste Sicherung zu packen. Dazu müssen aber dann auch die DTAARA's in die Hauptbibliothek. Das API schaue ich mir an.
Danke.

STRJRNOBJ OBJ(HUGOLIB/HUGO) OBJTYPE(*DTAARA) JRN(HUGOLIB/HUGOJRN)
CPF377F verweist im übrigen eindeutig auf commit definitions. Falls du sicher offene commit definitions ausschließen kannst, würde ich einen software defect melden, wäre nicht das erste PTF das die BReMSe für diesen Bereich braucht. Für den skizzierten Fall würde ich mal drüber nachdenken, ob der SAVACT(*YES) überhaupt gebraucht wird.

D*B

[holgerscherer]

und wo wir schon dabei sind - wer sich dem 24h Betrieb nähert, ist gut beraten, eine zweite Maschine mit Software-Spiegelung zu nehmen, und diese zu sichern...

-h

[KingofKning]

Tja, früher war die Hardware so gut das du mit einer AS/400 ausgekommen bist.
Aber vermutlich ist die Hardware auch nicht mehr so gut.
Hatte jetzt von einer großen Firma erfahren das sie 2 IBM Technikern Hausverbot erteilt haben weil sie einen nicht ganz unwichtigen Server lahmgelegt hatten.
Kam wohl nicht so gut an beim Kunden ;-)

Und wenn ich sehe das der deutschsprachige Support für Domino immer mehr ins Ausland verlagert wird, macht mich das auch nicht glücklich.

Mal sehen was die nächste Woche in Köln zu erzählen haben.


GG 4729

[BenderD]

Mal sehen was die nächste Woche in Köln zu erzählen haben.


GG 4729

lass mich raten (frei nach Peter Jacoby):IBM, schmatzi feini, böser Gregor, Gully oini...

D*B

[oulbrich]

und wo wir schon dabei sind - wer sich dem 24h Betrieb nähert, ist gut beraten, eine zweite Maschine mit Software-Spiegelung zu nehmen, und diese zu sichern...

In diesem Fall sollte man sich unbedingt auch das Thema FlashCopy anschauen.

http://newsolutions.de/it/flashcopy-und-ibm-i/

https://www.ibm.com/developerworks/community/blogs/5things/entry/five_things_to_know_about_flashcopy_and_ibm_i?lang =en

https://www.ibm.com/support/knowledg...s/flashcpy.htm

[holgerscherer]

In diesem Fall sollte man sich unbedingt auch das Thema FlashCopy anschauen.

Gerade auf einem hochaktiven In-Memory-System wie IBM i ist FlashCopy eher eine suboptimale Lösung im 24h-Betrieb...

-h
(holt Popcorn)