Setsamer sporadischer Fehler, MCH5804 + SQL0913

[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.

[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

[TARASIK]

Hallo Robi,
da gibt es einen Apar der IBM.
http://www-912.ibm.com/n_dir/nas4apa...ight=2,cpf1071
Dieses Ptf wurde ersetzt durch das aktuelle -> http://www-912.ibm.com/a_dir/as4ptf.nsf/ALLPTFS/SI60502

[Fuerchau]

Gut dem, der Fehler wiedererkennt und weiß wo die Lösung steht.

[Robi]

Prima, danke Tarasik!

ich geb's weiter, die EDV wird das PTF laden

Danke!

[petterr]

Ich befürchte das PTF wird das Problem nicht beheben. Es behebt nämlich so weit ich sehen kann nur einen Folgefehler dieses Problems, dass alle Ausgaben die nach dieser Meldung erfolgen an die Outq QEZDEBUG gesendet werden. Wir haben genau aus diesem Grund die Verwendung von Gruppenjobs schon lange aufgegeben, da das immer wieder zu Deadlocks führte.