korrupte message queue

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

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