QWCCCRVC zerstört

[j.k.]

Ich würds umgekehrt machen: Die Adresse des Programmobjekts in die SEPT kopieren.

Ist das denn die genaue Adresse für dieses Objekt?

Dann würd ich das mal ausprobieren...

[BenderD]

... nur so am Rande, wenn du dich da vermalst, kannst du die Lage übelst verschlimmbessern. Der dokumentierte Weg ist: Fehlermeldung und auf PTF warten.

D*B

[Fuerchau]

Bei V5R2 wirds da wohl nichts mehr geben.
Neu/Reparaturinstallation ist wohl der einzige Weg.

[Pikachu]

Ein DMPOBJ OBJ(QSYS/QWCCCRVC) OBJTYPE(*PGM) erstellt eine Spooldatei, in der die Adresse dieses Programmobjekts steht (links oben in der Spooldatei).

Ein DMPSYSOBJ OBJ(QINSEPT) CONTEXT(QSYS) TYPE(19) SUBTYPE(C3) erstellt eine Spooldatei, in der die Positionen der verschiedenen Programmobjekte in der SEPT stehen.

...
000530 SYP 02 01 QWCCCRVC 04 01 QSYS
...

Bei euch steht da vermutlich "Objekt zerstört".

Per STRSST > "Start a service tool" > "Display/Alter/Dump" > "Display/Alter storage" > "Machine Interface (MI) object" > "Space (19)" > "Find by object name and context name" kann der Inhalt des Objekts:

Object: (19) - Space / QINSEPT / C3
Context: QSYS / 01

unter "Hexadecimal, alter capable" angezeigt werden.

Hier sollte in der Zeile 1530 (!) an den Stellen XXXXXXXX XX die ersten 5 Bytes der Adresse (siehe oben) des Programmobjekts QWCCCRVC stehen.

1530 00048000 00000000 XXXXXXXX XX00023F

Überprüft das mal auf einem anderen System von euch (DMPOBJ um die Adresse zu ermitteln und STRSST um in die SEPT an Position 1530 zu sehen)!

Mittels "F11=Alter storage" können die Stellen XXXXXXXX XX geändert werden. (Vor dem Ändern unbedingt den vorherigen Inhalt notieren !!!)

Alle Angaben ohne Gewähr !!!
Seid vorsichtig beim Ändern !!!

[Fuerchau]

Auch wenn ihr mir nicht glauben wollt, aber Pointer unterliegen da einem besonderen Schutz.
Ändert man einen Pointer mit Daten, wird der Pointer zerstört und als Daten interpretiert.

Dies ist seit V5R1 so, damit man nicht mal eben aus Daten einen Pointer machen kann und somit Berechtigungen umgehen könnte oder sonstige Zugriffe erhält.
Im MI gibt es daher auch unterschiedliche Befehle:
CPYBLA -> Copy bytes
CPYBWP -> Copy with Pointer
Beim CPYBLA werden alle Bytes kopiert, ggf. enthaltene Pointer werden zerstört und sind nicht mehr als Pointer verwendbar.

Ich denke nicht, dass SST die Daten als Pointer erkennt und damit beim Überschreiben auch als Pointer, vor allem Systempointer, setzt.

Ich glaube auch nicht, dass die SEPT hier zerstört ist, da es beim direkten Aufruf mit der SEPT-Adresse sonst einen "Illegal Pointer"-Fehler geben würde.
Da aber das Objekt benannt wurde ist dieses irgendwie tatsächlich kaputt.
Das kann man zwar aus einem anderen System kopieren, wobei allerdings eine neue Adresse (Pointer) entsteht.

Meine Empfehlung, auch wenn's schwer fällt: Reparaturinstallation!

[Pikachu]

Auch wenn ihr mir nicht glauben wollt, aber Pointer unterliegen da einem besonderen Schutz.
Ändert man einen Pointer mit Daten, wird der Pointer zerstört und als Daten interpretiert.

Hier steht was Interessantes über diese MI-Zeiger. Demnach sind in der SEPT komplette MI-Zeiger drin, mit allen ihren 16 Bytes. Und durch Ändern des Segmentteils des Zeigers werden die ersten 8 Bytes, die den Typ des Zeigers enthalten, ja nicht gelöscht.

[Fuerchau]

Das mag ja alles so stimmen, aber nochmal, wenn du einen Pointer als Zeichen (16 Bytes) kopierst ist das Ziel kein Pointer mehr auch wenn ja alles bitweise identisch ist.
Ich denke auch das verändern einzelner Bytes zerstört den Pointer.

Wenn ich mal Zeit habe, probier ich das aus.

[Christian Bartels]

Das mag ja alles so stimmen, aber nochmal, wenn du einen Pointer als Zeichen (16 Bytes) kopierst ist das Ziel kein Pointer mehr auch wenn ja alles bitweise identisch ist.
Ich denke auch das verändern einzelner Bytes zerstört den Pointer.

Das gilt wohl, wenn man per Programm auf Adressen ändert. Wenn man den Pointer aber über SST ändert, hat man das selber in der Hand: Neben den Spalten mit den Daten gibt es eine Spalte "Tags active", und in der steht ein "T", wenn es sich um einen gültigen System Pointer oder Space Pointer handelt. Wenn man hier (z.B. in der SEPT) eine Adresse mit einem neuen Wert überschreibt und das "T" nicht rausnimmt, bleibt der Pointer gültig. Da in der SEPT sogenannte "System Pointer" stehen, also Pointer, die immer auf eine Segment Boundary verweisen(letzte drei Bytes = X'000000'), werden die beiden letzten Bytes für Zusatzinformationen verwendet: Das vorletzte Byte ist der Objekttyp (X'02' für Programm), das letzte Byte ist die Public Authority. Deshalb dürfen die beim der Reparatur nicht überschrieben werden.

Mit freundlichen Grüßen,
Christian Bartels.

[j.k.]

Ein DMPOBJ OBJ(QSYS/QWCCCRVC) OBJTYPE(*PGM) erstellt eine Spooldatei, in der die Adresse dieses Programmobjekts steht (links oben in der Spooldatei).

Ein DMPSYSOBJ OBJ(QINSEPT) CONTEXT(QSYS) TYPE(19) SUBTYPE(C3) erstellt eine Spooldatei, in der die Positionen der verschiedenen Programmobjekte in der SEPT stehen.

...
000530 SYP 02 01 QWCCCRVC 04 01 QSYS
...

Bei euch steht da vermutlich "Objekt zerstört".

Per STRSST > "Start a service tool" > "Display/Alter/Dump" > "Display/Alter storage" > "Machine Interface (MI) object" > "Space (19)" > "Find by object name and context name" kann der Inhalt des Objekts:

Object: (19) - Space / QINSEPT / C3
Context: QSYS / 01

unter "Hexadecimal, alter capable" angezeigt werden.

Hier sollte in der Zeile 1530 (!) an den Stellen XXXXXXXX XX die ersten 5 Bytes der Adresse (siehe oben) des Programmobjekts QWCCCRVC stehen.

1530 00048000 00000000 XXXXXXXX XX00023F

Überprüft das mal auf einem anderen System von euch (DMPOBJ um die Adresse zu ermitteln und STRSST um in die SEPT an Position 1530 zu sehen)!

Mittels "F11=Alter storage" können die Stellen XXXXXXXX XX geändert werden. (Vor dem Ändern unbedingt den vorherigen Inhalt notieren !!!)

Alle Angaben ohne Gewähr !!!
Seid vorsichtig beim Ändern !!!

Hallo Liebe Gemeinde!

Ich wollte euch nur an dieser Stelle informieren das ich das Object QWCCCRVC wieder herstellen konnte.

Ich habe mich an die Anleitung von Pikachu gehalten. Habe es mit Samthandschuhen und gestrichen voller Hose gewagt und gewonnen.

Nach dieser Anleitung hat es funktioniert. Nun kann ich wieder Data-Areas erstellen.

Vielen Dank nochmal für eure Hilfe und ein gutes
rüberkommen ins neue Jahr 2012!!!

Viele Grüße

Jan

[holgerscherer]

Auch wenn ihr mir nicht glauben wollt, aber Pointer unterliegen da einem besonderen Schutz.

Ich muss Dir da Deinen Glauben in die Sicherheit der AS/400 nehmen - sobald jemand (QSECOFR) Zugriff auf das DST/SST und Display/Alter/Dump hat - geht fast alles

Sogar eine Manipulation von Journalen. Daher sollte in zertifizierter Umgebung der Zugriff auf DAD gesperrt und genau protokolliert werden.

Andererseits ist die AS/400 trotzdem immer noch weitaus sicherer als der Rest der Welt. Habe da gewisse Erfahrungen als Gutachter - da wollte jemand mal unter Linux ein Logfile (textdatei) als Beweis anführen...


-h