korrupte message queue

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

[Fuerchau]

Im Endeffekt laboriert man hier an einem Problem das statistisch gesehen nie wieder vorkommen wird, aber was ist schon Statistik.

Da man nicht weiß wie CHKOBJ auf defekte Objekte reagiert bliebe ggf. eine andere Lösung:

Ein CLP, dass nur folgenden Befehl ausführt:
RCVMSG MSGQ(MYLIB/MYMSGQ)
WAIT(0)
RMV(*NO)

Dieses CLP wird submittet.
Der SBMJOB übergibt im Joblog die genaue Job-Id, die per RCVMSG ausgelesen werden kann.
Per JOBAPI wird geprüft, ob der Job beendet wurde. Ist dies der Fall, scheint die MSGQ ja i.O. zu sein, da der RCVMSG nicht hängen blieb.
Es muss natürlich sichergestellt werden, dass der Job auch sofort loslegt.
Zwischen SBMJOB und Job-API müsste ein DLYJOB(1) eigentlich reichen.