Beschädigtes Objekt löschen

[Flappes]

Hallo,

ich habe hier ein beschädigtes Objekt, welches ich weder löschen noch umbenennen kann.
Auch ein RSTOBJ bzw. ein Neuerstellen des DSPF funktioniert nicht.
Wie bekomm ich das Objekt weg?

Hier der Joblog-Fehler:
Speicher-Offset X'00000000' oder X'0000000000000000' liegt außerhalb der
aktuellen Grenze für Objekt XY001D.
Funktionsprüfung. MCH0601 nicht überwacht durch QDMROUTE bei Anweisung *N,
Instruktion X'019A'.

gruss christian

[Fuerchau]

Versuche mal das Objekt umzubenennen oder in die QRPLOBJ zu verschieben.

Andernfalls ist ein RCLSTG wohl erforderlich.

[Flappes]

Hi

Umbenennen als auch verschieben bringt den gleichen Fehler.
Auch nach einem Neustart hat sich nichts geändert.

gruss christian

[BenderD]

... wenn der SAVOBJ das auch nicht repariert kriegt, bleibt wohl nur ein RCLSTG

[Flappes]

So ...

hatte mal die Zeit gefunden für ein RCLSTG.
Im Joblog vom RCLSTG steht die gleiche Fehlernachricht.
Objekt lässt sich immer noch nicht löschen.

Nun ist guter Rat teuer.

[Fuerchau]

Wo du sagst teuer:
Da hilft nur eine Fehlermeldung an IBM.

[Pikachu]

Vielleicht kann man es im SST D/A/D selber umbenennen (Angaben erhält man über DMPOBJ) und dann nochmal einen RCLSTG laufen lassen. Aber ohne Gewähr!

[TARASIK]

Hallo,
also ich sehe da kein damage, denn die Nachricht "MSGMCH0601" sagt eigentlich nur aus, dass der Empfangswert zu klein ist, um das Ergebnis...
Nach beschädigten Objekten und Recovery kann mann auch hier mit suchen und beheben, aber ich vermute da besteht kein DAMAGE.
IBM i Support: Software Technical Document : 6493429

Nachrichten-ID . . . . . . . : MCH0601
Nachrichtendatei . . . . . . : QCPFMSG
Bibliothek . . . . . . . . : QSYS

Nachricht . . . : Speicher-Offset &2 oder &9 liegt außerhalb der aktuellen
Grenze für Objekt &1.
Ursache . . . . : Ein Programm hat versucht, einen Bereichszeiger
festzulegen, Speicher außerhalb eines Speicherbereichs zu verwenden oder
eine nicht zugeordnete Seite im Teraspace zu benutzen. Die Speicherklasse
ist &3. Die Speicherklasse legt die Art des Speicherbereichs fest:
00-zugeordneter Primärspeicher (einschließlich Speicherobjekte).
01-zugeordneter Sekundärspeicher &5.
02-impliziter Prozessspeicher für automatische Speicherung.
03-impliziter Verarbeitungsspeicher für statische Speicherung in
Aktivierungsgruppenmarkierung &10.
04-impliziter Verarbeitungsspeicher für Heap-ID &7 in
Aktivierungsgruppenmarkierung &10.

[Fuerchau]

Da es sich hier um ein Systemprogramm handelt ist trotzdem eine Meldung an IBM empfehlenswert.

[Christian Bartels]

Normalerweise versucht das System beim Löschen, alle Bestandteile eines Objektes mit zu erwischen. In diesem Falle scheint ein Pointer ins Nirwana zu führen, wodurch der Fehler kommt und das Objekt nicht gelöscht werden kann.

Meiner Erfahrung nach ist die Löschfunktion weniger empfindlich, wenn das Objekt als "beschädigt" markiert ist, d.h. das Objekt wird auch dann gelöscht, wenn nicht alle Pointer richtig stehen.

Man kann das "Hard Damage" Bit setzen, indem man über STRSST mit der Funktion Display/Alter/Dump in das Objekt geht (MI object). Wenn es sich um ein Display File handelt, müßte als Type 19 eingegeben werden, als Subtype 01. Context ist der Bibliotheksname. In der hexadezimalen Sicht steht auf Offset 0020 vorn der Wert 8100. Wenn man den mit A100 überschreibt und F11 für "Alter Storage" drückt, hat man das Objekt als beschädigt markiert. Danach läßt es sich in der Regel löschen, allerdings sollte man danach irgendwann nochmal einen RCLSTG machen, um eventuelle Reste zu beseitigen. Das hat dann aber mehr kosmetischen Charakter, wirklich nötig ist es nicht.

Mit freundlichen Grüßen,
Christian Bartels.

P.S.: Die Umsetzung der Anleitung geschieht auf eigene Verantwortung, im Zweifelsfall ist es besser, das Problem an den IBM-Support zu melden und die machen zu lassen.