korrupte message queue

[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.

[AS400.lehrling]

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

Komisch, als ich das letzte mal zu Testzwecken den Netzstecker einer 170er zog gab es sofort eine Meldung an QSYSOPR und das System wurde innerhalb der Überbrückungsgrenze herunter gefahren.

Sicher das ihr das richtige Kabel zwischen USV und i5 habt

Da gibt es ja bei einigen Modellen ein Spezielles Adapterkabel zum ausgleich geänderter Pinbelegung.

Gruß AS400.lehrling

[Pikachu]

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.

Dann ab damit ins Startprogramm, welches im Systemwert QSTRUPPGM angegeben ist.

[Matthias182]

Dann ab damit ins Startprogramm, welches im Systemwert QSTRUPPGM angegeben ist.

Jetzt bin ich aber komplett verwirrt.

Ich möchte die message queue nicht generell löschen, sondern nur, wenn sie defekt ist. Und das will ich natürlich vorher prüfen.

Mir scheint mittlerweile, dass mein Vorhaben mehr als schwierig ist und ich glaube im Moment auch nicht zu einem Ergebnis führt.

Ich schaffe es weder diese Situation nachzustellen, noch eine vernünftige Methode zu entwickeln um solche Objekte zu prüfen.

Das mit dem Herunterfahren stimmt, jedoch ist der entsprechende Systemwert so eingestellt, dass die Machine hier nichts unternimmt (ich glaube QUPSDLYTIM). Unsere Maschinen werden 24h im Rechenzentrum überwacht. Leider gab es hier ein menschliches Versagen, das den Fehler am Ende bedingt hat.

[Pikachu]

Ich möchte die message queue nicht generell löschen, sondern nur, wenn sie defekt ist. Und das will ich natürlich vorher prüfen.

Dann bleibt dir wohl nur der Weg mittels MI (Machine Interface), wobei eine Nachrichtenwarteschlange wie es aussieht in der Systemdomäne liegt und ab Sicherheitsstufe 40 nur von Programmen mit Systemstatus darauf zugegriffen werden kann. Und du brauchst noch eine detailierte Beschreibung von IBM, wie eine Nachrichtenwarteschlange (je nach Systemrelease) aufgebaut ist, um sie prüfen zu können.