-
Setsamer sporadischer Fehler, MCH5804 + SQL0913
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
PHP-Code:
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
PHP-Code:
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
PHP-Code:
OP TREE LOCKED BY JOB
Das Pgm CHKEXA macht:
PHP-Code:
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
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
ach ja,
sporadisch heist ...
alle 6-7 Wochen mal
der Ablauf läuft täglich mehrere Stunden, die iSeries fährt jede Nacht runter
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
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.
-
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?
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
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.
-
Hallo,
kann es sein das eventuelle Sicherungen oder etwas in der Richtung vorliegt ?
z.B. Spiegelung ?
Gruß
Michael
-
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.
-
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?
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
Zitat von 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.
... 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
-
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.
-
Also ne Spiegelung läuft dort nicht.
Sicherung ist auch ausgeschlossen.
Des weiteren ist die Datei auch an anderen Programmen dran. Das setzen einer exklusiven Sperre ist daher recht unwahrscheinlich. Wir haben nun die EDV Mitarbeiter angewiesen, beim nächsten mal mit WRKOBJLCK und *Print nach Sperren zu suchen.
Außerdem werden wir mal aktuelle PTF's einspielen.
Danke
Robi
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
@Fuerchau
Ja, ok, Wenn es eine Sperre gibt, ist das logisch, danke.
Z.Zt wird aber bezweifelt das eine Sperre gesetzt wird, da das 'absichtlich' nie für irgendeine Datei gemacht wird. Unter Tags keine Reorg und keine DaSi läuft und ich keine Kodierung in der zu 90% selbst gebauten SW finde.
Auf der Datei liegen keine LF in anderen Libs und auch keine Views.
Es ist schon etwas seltsam und nicht nachstellbar
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
Similar Threads
-
By svit in forum NEWSboard Programmierung
Antworten: 4
Letzter Beitrag: 01-03-19, 19:03
-
By oulbrich in forum NEWSboard Programmierung
Antworten: 7
Letzter Beitrag: 23-03-15, 17:21
-
By malzusrex in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 23-04-03, 17:15
-
By Pia in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 17-03-03, 12:22
-
By K_Tippi in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 05-12-02, 11:41
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks