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.

[Robi]

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

[Robi]

@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