korrupte message queue

[Matthias182]

Hallo zusammen,

ich beschäftige mich gerade mit einem Thema, dass mir einiges an Kopfzerbrechen bereitet.

Wir hatten auf einer unserer Maschinen einen Zwischenfall bedingt durch eine korrupte message queue.

Um das Ganze zukünftig zu vermeiden, suche ich nun nach einer Lösung, um eine korrupte message queue rechtzeitig erkennen zu können.

Ich weiß, dass man bei einer data queue über DSPOBJD sehen kann, ob sie korrupt ist oder nicht. Würde das auch mit einer message queue funktionieren?

Bei Dateien kann man ja soweit ich weiß mit RCLSTRGarbeiten, aber das funktioniert dann nicht für message queues.

Zuletzt die merkwürdigste meiner Fragen. Ich würde das Ganze natürlich gerne nochmal nachstellen. Dazu benötige ich allerdings eine korrupte message queue. Hat jemand eine Idee, wie man das System austricksen kann, um eine solche message queue zu erzeugen?

Ich hoffe, ihr habt hier mehr gute Ideen als ich bisher.


Gruß
Matthias

[Pikachu]

Beschädigte Nachrichtenwarteschlangen sind ja kein Normalzustand und sowas kommt ja auch nicht alle Tage vor. Welche Nachrichtenwarteschlange war es denn und was waren die Auswirkungen?

[Matthias182]

Ja, das stimmt natürlich, jedoch sollten Anwendungen natürlich so robust wie möglich sein.

Es handlete sich um eine eigene Warteschlange, keine des Systems.

Der zugehörige Job hat versucht Nachrichten zu empfangen, konnte dies jedoch nicht. Es war auch nicht möglich den Job zu beenden. Nur das Beenden des Subsystems half hier (IBM war da auch involviert).

Wie gesagt, jetzt möchte ich an dieser Stelle in der Entwicklung besser werden und den Fehler vorher erkennen.

[Fuerchau]

Beschädigte Objekte können nur per RCLSTG wiederhergestellt bzw. entfernt werden. Dies betrifft leider das gesamte System.

Du kannst es ggf. mit RCLLIB versuchen, aber die Doku gibt da nicht viel her.

Du kannst auch versuchen per CHKOBJ das Objekt einfach zu prüfen, wobei ich nicht weiß, wie der Befehl auf beschädigte Objekte reagiert. Allerdings kann das Objekt dann auch nur per RCLSTG entfernt werden.

[Pikachu]

Manchmal kann man ein beschädigtes Objekt auch selber löschen.

Der Befehl SAVOBJ prüft Objekte auch darauf, ob sie beschädigt sind. Vielleicht kannst du versuchen, das Objekt mit SAVOBJ PRECHK(*YES) in eine Sicherungsdatei zu sichern und dann prüfen ob das funktioniert hat.

[Matthias182]

Hallo,

wenn ich das aber richtig verstehe, dann handhabt RCLSTG jedoch nur database files, libraries, device descriptions, directories, stream files und user profiles.

Es scheint hier keine Möglichkeit zu geben, um eine message queue zu korrigieren.

Habt ihr eine Idee, wie ich eine korrupte message queue erzeugen kann, um ein paar Tests zu machen? Ansonsten können wir nur spekulieren.


Dnake und Gruß
Matthias

[Pikachu]

Der RCLSTG prüft eigentlich noch mehr Objekte, näheres siehe diese Beschreibung.

Objekte mutwillig zu beschädigen ist möglich, aber willst du das wirklich? Es kann sicher auch verschiedene Arten von Beschädigungen geben und ob man alle prüfen kann? Ist die Maschine denn im produktiven Einsatz?

Wie oft war die betreffende Nachrichtenwarteschlange denn schon beschädigt?

[Matthias182]

Ich habe hier verschiedene Systeme zur Verfügung (Entwicklung-, Test und Produktionssysteme).

Bisher ist das noch nicht vorgekommen. Es handelt sich nicht um eine System-Warteschlange, sondern um eine eigene.
Das Problem ist durch einen Stromausfall entstanden, der nicht rechtzeitig erkannt wurde.

Und nach dem Wiederanlauf, haben wir nicht erkannt, dass diese Warteschlange beschädigt war. Für solche sehr seltenen Fälle müssen wir jetzt aber eine Routine haben, die in der Lage ist diesen Fehler vorher zu erkenen, ohne die Produktion zu beeinträchtigen.

[Fuerchau]

Da hilft dann für das nächste Mal halt ein RCLSTG, wenn das System abnormal beendet wurde, und das weiß man doch hoffentlich.

[Matthias182]

Hallo Fuerchau,

der RCLSTG ist bekannt und wurde nach dem Absturz auch angewendet.

Jedoch hat das für die message queue nichts gebracht. Ich bin nach wie vor der Ansicht, dass der Befehl bei Nachrichtenwarteschlangen nichts bringt bzw. nicht funktioniert.


Gruß
Matthias

[Pikachu]

Hattet ihr ne USV an der Maschine?

Falls die Nachrichten in der betreffenden Nachrichtenwartschlange nach einem IPL nicht wichtig sind, könnt ihr sie doch immer nach einem IPL löschen und neu anlegen.

[Matthias182]

Ja, USV gibt es, allerdings wurde der Stromausfall nicht richtig erkannt.

Ein Löschen nach dem IPL wäre zwar denkbar, allerdings war die Maschine bereits wieder produktiv nach einer erheblichen Ausfallzeit. Da möchte nicht noch jemand einen IPL machen, nur weil ein Hintergrundprozess Probleme mit einer Warteschlange hat.

Wie gesagt, Intention war daher die Möglichkeit so etwas zu prüfen, bevor man wieder produktiv geht.

Das Ganze Szenario wurde auch schon von IBM untersucht und wird soweit ich weiß in einem PTL enden.