Setsamer sporadischer Fehler, MCH5804 + SQL0913

[Robi]

Hallo *all

wir haben auf einem Kundensystem unter V7R1 folgendes Phänomen.

Mehrere Mitarbeiter sind an eine Telefonanlage angeschlossen.
Bekommen Sie einen Anruf 'sucht' die Software aufgrund der Telefonnr. den Kunden und ruft, als Gruppenjob, das Info/Bearbeitungspgm mit dem vor geblendeten Kunden.

Ab und zu hängt sich die gesamte Konstruktion auf, ALLE Mitarbeiter schreiben Joblogs ohne ende.
Als Ursache haben wir einem Job, auf den von allen anderen verwiesen wird. Dort steht in den Joblogs: MCH5804


20 21.06.16 11:13:04,459606 < ckSpaceLoc 000F08 QSQRUN3 QSYS
Ausgangsprogramm . . . . . : RmslLockSpaceLoc
Zielmodul . . . . . . . . . : QSQOPEN
Zielprozedur . . . . . . . : BQDTAP
Anweisung . . . . . . . . . : 28958
Nachricht . . . : Sperroperation für Bereich konnte im spezifizierten
Zeitintervall nicht durchgeführt werden.
Ursache . . . . : Das angegebene Zeitintervall von 30 Sekunden ist
verstrichen, und eine Sperroperation für die Speicherposition oder die
Teraspace-Speicherposition wurde nicht ausgeführt. Die Sperrenhalterart ist
1. Der Name des Sperrenhalters ist AAABBBCC AAABBB 391568. Die Thread-ID
des Sperrenhalters ist X'0000000000000001'. Die Sperrenhalterart hat
folgende Bedeutung: 0 - Der Sperrenhalter ist eine LIC (lizenzierter
interner Code)-Task. Name des Sperrenhalters und Thread-ID gelten nicht. 1 -
Der Sperrenhalter ist ein Job. 2 - Der Sperrenhalter ist eine
Transaktionssteuerstruktur. Name des Sperrenhalters und Thread-ID gelten
nicht.

Anschließend kommt

CPF9898 Information 40 21.06.16 11:13:04,471923 QSQRUN3 QSYS *STMT QSQRUN3 QSYS *STMT
Ausgangsmodul . . . . . . . : QSQOPEN
Ausgangsprozedur . . . . . : SQDUMPOPLCKINFO
Anweisung . . . . . . . . . : 28240
Zielmodul . . . . . . . . . : QSQOPEN
Zielprozedur . . . . . . . : SQDUMPOPLCKINFO
Anweisung . . . . . . . . . : 28240
Nachricht . . . : DEBUG DATA WAS SENT TO OUTQ QUSRSYS/QEZDEBUG.
Ursache . . . . : Diese Nachricht wird von Anwendungsprogrammen als allgemeine Abbruchnachricht verwendet.
CPF1071 Abbruch 40 21.06.16 11:13:04,828734 QWCCDSJC QSYS 16DF QSQRUN3 QSYS *STMT
Zielmodul . . . . . . . . . : QSQOPEN
Zielprozedur . . . . . . . : SQDUMPOPLCKINFO
Anweisung . . . . . . . . . : 28317
Nachricht . . . : Keine Berechtigung für Job 391568/AAABBB/AAABBBCC.
Ursache . . . . : Es wurde versucht, den Job mit einem anderen Benutzernamen
anzuzeigen, und es besteht keine Berechtigung zur Jobsteuerung (*JOBCTL).
Fehlerbeseitigung: Vom Sicherheitsbeauftragten die Berechtigung zur
Jobsteuerung besorgen. Anschließend die Anforderung wiederholen.
SQL0913 Diagnose 30 21.06.16 11:13:12,371283 QSQRUN3 QSYS *STMT QSQRUN3 QSYS *STM
Ausgangsmodul . . . . . . . : QSQOPEN
Ausgangsprozedur . . . . . : CLEANUP
Anweisung . . . . . . . . . : 26719
Zielmodul . . . . . . . . . : QSQOPEN
Zielprozedur . . . . . . . : CLEANUP
Anweisung . . . . . . . . . : 26719
Nachricht . . . : Zeile oder Objekt CHKEXA der Art *PGM in BBBBBB wird
verwendet.
Ursache . . . . : Das angeforderte Objekt CHKEXA der Art *PGM in der
Bibliothek BBBBBBB wird gerade von einem anderen Anwendungsprozeß
verwendet, oder eine Zeile im Objekt wird von einem anderen Anwendungsprozeß
oder einem anderen Cursor in diesem Anwendungsprozeß verwendet.
Fehlerbeseitigung: Die vorherigen Nachrichten im Jobprotokoll aufrufen
(Befehl DSPJOBLOG) oder im interaktiven SQL F10 (Nachrichten im Jobprotokoll



Die Meldung mit der Berechtigung ist nicht begründbar. Der Job will (normalerweise) nix von dem anderen Job, die kennen sich nicht. Da versucht hier das System anscheinend aufgrund der festgestellten Sperre etwas zu machen, für das keine Berechtigung besteht.

Der "Verursacher" erzeugt einen SQL SRV Dump mit diesem Eintrag


OP TREE LOCKED BY JOB


Das Pgm CHKEXA macht:


C/EXEC SQL
C+ whenever sqlerror go to ABBRUCH
C/END-EXEC
C*
C/EXEC SQL
C+ whenever not found go to NOT_FOUND
C/END-EXEC
C*
C/EXEC SQL
C+ declare C1 cursor for
C+ select * from EXTADL03 a
C+ where a.EAADKZ = :PRM_ADKZ
C+ and a.EAORT = :PRM_ORT
C+ and a.EALDKZ = :PRM_LDKZ
C+ and a.EAPLZ = :PRM_PLZ
C+ and a.EASTRA = :PRM_STR
C+ for fetch only
C/END-EXEC
C*
C/EXEC SQL
C+ open C1
C/END-EXEC
C*
C/EXEC SQL
C+ fetch C1
C/END-EXEC
C*
C GOTO ENDE
...
...
C ENDE TAG
C*
C/EXEC SQL
C+ close C1
C/END-EXEC
C*
C RETURN

Ich vermute, das 'irgendwas' mit dem Gruppenjob und dem Basis job durcheinander kommt.
Die Anwender arbeiten 'normal' auch in dem Info/Bearbeitungspgm, dort wird also auch des öfteren das CHKEXA aufgerufen
Hat jemand eine Idee?
Danke


Robi

[Robi]

ach ja,
sporadisch heist ...
alle 6-7 Wochen mal

der Ablauf läuft täglich mehrere Stunden, die iSeries fährt jede Nacht runter

[Fuerchau]

SQL muss für bestimmte Aktionen auch auf andere Job's zugreifen.
Der Grund sind die ODP's, die ja von SQL offen gehalten werden.
Ist eine Datei durch SQL offen aber es greift kein Cursor aktuell zu, kann an der Tabelle/PF trotzdem eine Änderung gemacht werden da die ODP's dann zwangsgeschlossen werden.
Mit tatsächlich offenen Dateien durch F-Bestimmungen geht das nicht.

Was immer da also als Ressource benötigt wird (hier also wahrscheinlich ein Shared-Read) ist durch eine Blockade in einem anderen Job nicht möglich. Hierzu ist dann die Sperre des anderen Jobs und was der gerade macht, zu überprüfen.

[Robi]

Moin,
ja, danke soetwas könnte es sein.

Aber das CHKEXA Pgm liest ja nur! Der dürfte m.e. keine Sperre setzen.
Und wenn der nicht lesen kann, weil der Satz ggf gesperrt ist
(geht das, in einer Anwendung OHNE Commit?)
dürften doch die anderen Jobs, die definitiv auf ANDERE Sätze zugreifen wollen nicht auf eine Sperre laufen?
oder?

[Fuerchau]

Wie du laut Dump sehen kannst, scheitert der nicht am Lesen sondern bereits am Open (QSQOPEN).
D.h., es muss eine nicht freigegebene exclusive Sperre der Datei selber anliegen so dass der Open mit Time-Out fehlschlägt.

[mk]

Hallo,

kann es sein das eventuelle Sicherungen oder etwas in der Richtung vorliegt ?
z.B. Spiegelung ?
Gruß
Michael

[Fuerchau]

Spiegelung arbeitet i.d.R. mit Journalen, Datensicherung um 11:13 Uhr halte ich für unwahrscheinlich.
Zu prüfen ist halt, welcher Job um diese Zeit eine Exclusiv-Sperre länger als 30 Sekunden hält.

[Robi]

es muss eine nicht freigegebene exclusive Sperre der Datei selber anliegen
Hmm,
das hab ich gerade zur Sicherheit überprüft!

Weder in den CL's noch in den RPG's wir die Datei gelockt(hätte mich auch gewundert).


Sicherung ...
Unwahrscheinlich, aber nicht unmöglich. Da geh ich mal in die Forschung ...

kann es noch etwas geben, das die Datei sperrt?

[BenderD]

Spiegelung arbeitet i.d.R. mit Journalen, Datensicherung um 11:13 Uhr halte ich für unwahrscheinlich.
Zu prüfen ist halt, welcher Job um diese Zeit eine Exclusiv-Sperre länger als 30 Sekunden hält.

... beim RESYNC einer Placebo-HA-Saftware sieht das schon anders aus - ansonsten tipp ich mal auf einen Bug. SQL lässt selbst im Härtefall immer noch SHRRD zu.

D*B

[Fuerchau]

Aktuel bei V7R1 noch mal ausprobiert:
Sitzung 1: ALCOBJ MYFILE *FILE *EXCL
Sitzung 2: per STRSQL "Select * from Myfile"
Ergebnis Joblog:
CPF4270 Zuordnung von Teildatei DBUTF8, Art *FILE nicht möglich.
CPD6DEF 040217/FUERCHAU/FUERCHAUS1 HOLDS *EXCL LOCK FOR FUERCHAU/DBUTF8
MCH3402 Es wurde versucht, auf ein nicht mehr vorhandenes Objekt oder Teile des Objekts Bezug zu nehmen.
SQL0913 Zeile oder Objekt DBUTF8 der Art *FILE in FUERCHAU wird verwendet.
MCH3402 Es wurde versucht, auf ein nicht mehr vorhandenes Objekt oder Teile des Objekts Bezug zu nehmen.
Der SQL0913 als Endergebnis ist korrket, der MCH-Fehler wird wohl von STRSQL (QSQISE) abgefangen.
Der QSQOPEN (Embedded SQL) ist da wohl nachlässiger und stirbt daran.
Ein Lesen der Daten ist also nicht möglich.