QSYGETPH API

[Fuerchau]

Da hat man nun schlechte Karten.
Systemobjekte sind z.T. intern verlinkt.
Durch das Überschreiben ist der interne Link aufgehoben worden.
Dies bekommt man ggf. nur per Neuinstallation des OS wieder hin.

http://www-01.ibm.com/support/docvie...d=nas8N1019748

[emkata]

Die Meldung ist CPF9190 mit Ursachencode 15.
Nachricht . . . : Berechtigungsfehler beim Versuch, eine DRDA/DDM
TCP/IP-Verbindung herzustellen.
15 -- Sicherheitsverarbeitung am Server fehlgeschlagen.

Wir hatte auch die Befürchtung mit einer internen Verlinkung :-(

So sieht die Berechtigung aus:

Objektberechtigung anzeigen

Objekt . . . . . . . : QSYGETPH Eigner . . . . . . . : QSYS
Bibliothek . . . . : QSYS Primärgruppe . . . . : *NONE
Objektart . . . . . : *PGM ASP-Einheit . . . . : *SYSBAS

Objekt durch Berechtigungsliste geschützt . . . . . . . . . . : *NONE

Objektbe- ------------Objekt------------
Benutzer Gruppe rechtigung Opr Verw Exist. Ändern Ref
*PUBLIC *USE X
QSYS *ALL X X X X X
QRDARS400 *USE X
QSRV *USE X

[BenderD]

... das ist doch der Fehler auf dem client, sprich der anfordernden Maschine? Wie sieht das auf der Serverseite aus? Müsste im Joblog von QRWTSRVR zu finden sein.
D*B

[emkata]

Ich hoffe, dass ich eine der richtigen Joblogs erwischt habe. Da sind schon einige.


5761SS1 V6R1M0 080215 Jobprotokoll anzeigen FSY 16.03.18 11:26:19 Seite 1
Jobname . . . . . . . . . . : QRWTSRVR Benutzer . . . . : QUSER Nummer . . . . . . . . . . . : 491683
Jobbeschreibung . . . . . . : QDFTSVR Bibliothek . . . : QGPL
NACHR-ID ART BEW DATUM ZEIT VON PGM BIBLIOTHEK INST AN PGM BIBLIOTHEK INST
CPF1124 Information 00 16.03.18 11:22:31,058865 QWTPIIPP QSYS 04C0 *EXT *N
Nachricht . . . : Job 491683/QUSER/QRWTSRVR im Subsystem QUSRWRK in QSYS am
16.03.18 um 11:22:30 gestartet. Job im System am 16.03.18 um 11:22:30.
angekommen.
CPI9162 Information 00 16.03.18 11:26:19,171178 QCNTEDDM QSYS *STMT QRWTSRVR QSYS *STMT
Ausgangsmodul . . . . . . . : QCNTEDDM
Ausgangsprozedur . . . . . : SNDMSG
Anweisung . . . . . . . . . : 7978
Zielmodul . . . . . . . . . : QRWTSRVR
Zielprozedur . . . . . . . : main
Anweisung . . . . . . . . . : 352
Nachricht . . . : Der für die Bearbeitung der DDM-Verbindung zugeordnete
Zieljob wurde vom Quellensystem über TCP/IP gestartet.
Ursache . . . . : Job 644500/JOHNDO/BACKUP auf Quellensystem FSY startete
eine DDM-Verbindung über TCP/IP. Siehe Quellenjob 644500/JOHNDO/BACKUP für
alle weiteren Nachrichten bezüglich der DDM-Verbindung. DDM verwendet die
ferne IP-Adresse 192.168.70.13 und den fernen Port 32787 für diese
TCP/IP-Verbindung.
MCH3402 Abbruch 40 16.03.18 11:26:19,220110 < allProgram 001F7C QRWTSECR QSYS *STMT
Ausgangsprogramm . . . . . : AiUpcallProgram
Zielmodul . . . . . . . . . : QRWTSECR
Zielprozedur . . . . . . . : PRCSECMEC
Anweisung . . . . . . . . . : 5745
Nachricht . . . : Es wurde versucht, auf ein nicht mehr vorhandenes Objekt
oder Teile des Objekts Bezug zu nehmen.
Ursache . . . . : Die häufigste Ursache ist, dass eine gespeicherte Adresse
für ein Objekt nicht mehr korrekt ist, da das Objekt ganz oder teilweise
gelöscht wurde.
CPF3E86 Diagnose 40 16.03.18 11:26:19,220270 QRWTERR QSYS *STMT QRWTSECR QSYS *STMT
Ausgangsmodul . . . . . . . : QRWTERR
Ausgangsprozedur . . . . . : SNDMSG
Anweisung . . . . . . . . . : 8687
Zielmodul . . . . . . . . . : QRWTSECR
Zielprozedur . . . . . . . : HNDRWERR
Anweisung . . . . . . . . . : 6399
Nachricht . . . : Fehler bei der Verarbeitung verteilter Datenbanken
aufgetreten.
Ursache . . . . : Während der Verarbeitung der verteilten relationalen
Datenbank trat ein interner Fehler auf. Positionscode X'02'. Die Codes sind:
-- '01'X -- Der Fehler trat beim Anwendungsrequester auf. -- '02'X -- Der
Fehler trat beim Anwendungsserver auf. Fehlerbeseitigung: Das Problem
melden (Befehl ANZPRB). Technische Beschreibung . . . . . . . : Die
Fehlerinformation ist X'99'. Dies führt zu SQLCODE -30000 oder -30020 und
SQLSTATE 58008 oder 58009 beim Anwendungsrequester.
SQ30020 Diagnose 30 16.03.18 11:26:19,220296 QRWTERR QSYS *STMT QRWTSECR QSYS *STMT
Ausgangsmodul . . . . . . . : QRWTERR
Ausgangsprozedur . . . . . : SNDMSG
Anweisung . . . . . . . . . : 8687
Zielmodul . . . . . . . . . : QRWTSECR
Zielprozedur . . . . . . . : HNDRWERR
Anweisung . . . . . . . . . : 6399
Nachricht . . . : DRDA-Protokollfehler.
Ursache . . . . : Der Befehl oder die SQL-Anweisung ist infolge eines
Verteilungsprotokollfehlers, der sich auf nachfolgende Befehle oder
SQL-Anweisungen auswirken wird, fehlgeschlagen. Die Verbindung zur Anwendung
wurde unterbrochen und der Prozeß befindet sich in einem Status ohne
Verbindung. Der Protokollfehler ist X'1254' mit dem Positionscode X'02'. Die
Positionscodes sind: -- '01'X -- Der Fehler wurde im Anwendungs-Requester
5761SS1 V6R1M0 080215 Jobprotokoll anzeigen FSY 16.03.18 11:26:19 Seite 2
Jobname . . . . . . . . . . : QRWTSRVR Benutzer . . . . : QUSER Nummer . . . . . . . . . . . : 491683
Jobbeschreibung . . . . . . : QDFTSVR Bibliothek . . . : QGPL
NACHR-ID ART BEW DATUM ZEIT VON PGM BIBLIOTHEK INST AN PGM BIBLIOTHEK INST
erkannt. -- '02'X -- Der Fehler wurde im Anwendungsserver erkannt. Mögliche
Protokollfehler sind: -- '1218'X -- Nicht unterstützte Funktion angefordert.
Der Fehlercode lautet X'99'. -- '1232'X -- Unerwarteter permanenter Fehler.
-- '1245'X -- Dialogprotokollfehler. Der Fehlercode lautet X'99'. -- '1254'X
-- Unerwartete Fehlerbedingung. Der Fehlercode lautet X'99'. Ist der
Protokollfehler in der Liste nicht aufgeführt, im Handbuch "DDM Architecture
Reference" unter DDM-Codepunkt X'1254' nachschlagen. Fehlerbeseitigung: Das
Problem mit dem Befehl ANZPRB (Problem analysieren) melden.
CPF93B6 Information 10 16.03.18 11:26:19,368875 QPDSERR QSYS 0A03 QRWTSECR QSYS *STMT
Zielprozedur . . . . . . . : CALLFFDCMAC
Anweisung . . . . . . . . . : 6878
Nachricht . . . : Problemprotokoll aktualisiert.
Ursache . . . . : Es wurde ein Problem auf dem System festgestellt. Es wurde
jedoch kein Problemprotokolleintrag erstellt. Der Grund hierfür ist ein
bereits vorhandener Problemprotokolleintrag, der dieses Problem beschreibt.
Die vorhandene Problemprotokolleintrags-ID 1807347935 wurde aktualisiert.
Damit wird angezeigt, dass das Problem erneut aufgetreten ist.

[BenderD]

MCH3402 Abbruch 40 16.03.18 11:26:19,220110 < allProgram 001F7C QRWTSECR QSYS *STMT
Ausgangsprogramm . . . . . : AiUpcallProgram

... das sieht ganz nach dem von Baldur beschriebenen Problem aus. V6R1M0 - da tippe ich mal blind, dass IBM sich da taub stellt und EOS (end of support) reklamiert. Das sieht ganz nach einem refresh des Betriebssystems vom letzten SAVSYS aus. Da ist allerdings sorgfältiges Vorgehen gefragt und einiges zu beachten.


D*B

[Fuerchau]

Das API wird natürlich auch vom System selber benutzt.
Hierzu wird im System eine Pointer-Liste auf Programmobjekte bei Systeminstallationen und PTF-Updates verwaltet, die sog. QINSEPT.
Wenn man mit C/C++ programmiert, kann man auf diese Liste zugreifen und sich somit die Zeiten zur Initialisierung des Systempointers sparen.
Über die QINSEPT wird auch z.B. von den HLL-Runtimes (RPG/LE, COBOL, usw.) auf die DB-Routinen zugegriffen.
Man kann sich also darauf verlassen, wenn man einen CALL QInsept(IndexOfQCMDEXC) durchführt, dass dieser auch klappt.

Die obige Meldung "Es wurde versucht, auf ein nicht mehr vorhandenes Objekt oder Teile des Objekts Bezug zu nehmen." deutet eben auf den fehlenden/korrupten Pointer des QSYGETPH hin womit dann eben die Berechtigung aus DDM nicht mehr geprüft werden kann und somit nicht von Erfolg gekrönt wird.

Eine Reparatur mit Bordmitteln ist mir nicht bekannt.
Man kann auch kein MI/C-Programm zur Korrektur der QINSEPT mehr schreiben, da das Objekt über die System-Domäne geschützt ist.

Der Link deutet ja genau auf das Problem des "AiUpcallProgram" hin.

[emkata]

Danke Euch!

Es sieht wirklich danach aus, dass wir eine Neu-Installation machen müssen.

[BenderD]

Eine Reparatur mit Bordmitteln ist mir nicht bekannt.

... man kann da wohl schon noch mit patch drin rummalen, aber das ist dann auch die Lizenz dazu die Maschine völlig abzuschießen...

D*B

[Fuerchau]

Das Problem der QINSEPT ist die fehlende Doku, auf welchem Eintrag denn welches Programm steckt.
Vielleicht gibt es in der QSYSINC (Bibliothek zum Installieren) noch eine Definition.
Dann könnte man (wie im Link beschrieben) wohl per SST den kaputten Pointer wieder auf das Programm setzen.

[BenderD]

... die Reihenfolge ist bei passendem Release wohl immer dieselbe und man kann die Tabelle wohl dumpen, da gibt es irgendwo eine Beschreibung. Die pointer müssten dann angepasst werden auf die konkrete Adresse auf der Büchse. Das ist aber alles ohne Netz und doppelten Boden - das würde ich allenfalls auf einer Museumsbüchse von Holger oder Gregor probieren. Ich habe in einem meiner vorherigen Leben einmal mit SST in der Plattenkonfig rumgemalt - das war aber eine Testbüchse und das Stresslevel gleichwohl immens hoch...

D*B

[Fuerchau]

Als ich noch mit V2R1 gearbeitet hatte und meine ersten MI-Progrämmchen schrieb, habe ich mir die QINSEPT auch zerhauen (da gabs noch keinen Schutz), da ich einen Pointer bewusst umgebogen hatte. Durch einen Fehler konnte ich allerdings das Original nicht mehr einstellen, so dass hier auch eine Neuinstallation nötig wurde (ca. 1992;-)).

[Pikachu]

Mit DMPSYSOBJ OBJ(QINSEPT) CONTEXT(QSYS) kann man den Inhalt der SEPT ansehen und mit DMPSYSOBJ OBJ(QSYGETPH) CONTEXT(QSYS) OBJTYPE(*PGM) bekommt man die Adresse des Programms QSYGETPH. Mit Hilfe von STRSST Display/Alter/Dump kann man die linken 5 Bytes (!) der Adresse des Programms an die richtige Stelle in die SEPT eintragen. Einfach mal auf dem anderen System nachsehen (im Inhalt der SEPT nach QSYGETPH suchen und die Stelle in der SEPT ermitteln) und anschließend auf dem betroffenen System machen (Vorsicht: Die Adressen der beiden Systeme nicht durcheinanderbringen!) Anschließend mit DMPSYSOBJ die SEPT prüfen...