View Full Version : Setsamer sporadischer Fehler, MCH5804 + SQL0913
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
@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
Hallo Robi,
da gibt es einen Apar der IBM.
http://www-912.ibm.com/n_dir/nas4apar.nsf/c79815e083182fec862564c00079d117/65d99f97f8a19f3c8625786f003c7387?OpenDocument&Highlight=2,cpf1071
Dieses Ptf wurde ersetzt durch das aktuelle -> http://www-912.ibm.com/a_dir/as4ptf.nsf/ALLPTFS/SI60502
Gut dem, der Fehler wiedererkennt und weiß wo die Lösung steht.
Prima, danke Tarasik!
ich geb's weiter, die EDV wird das PTF laden
Danke!
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.
Gruppenjobs haben auf jeden Fall das Problem, dass die inaktiven Jobs tatsächlich nicht reagieren können.
Da ja die obige Lösung den aktuellen Job tatsächlich unterbricht und auf einen anderen Job wechselt können ggf. laufende SQL-Threads auf globale Anforderungen nicht mehr reagieren.
An Stelle auf einen Gruppenjob zu wechseln kann man ja ein anderes Programm aufrufen.
Wenn dieses eine eigene ACTGRP hat kann es sich auch seine Zustände merken um bei erneutem Aufruf, egal aus welcher Jobtiefe, entsprechend reagieren.
Um einen Job zu unterbrechen kann man sich (wie D*B schon mal beschrieben) einen BRKMSG-Handler installieren, der den laufenden interaktiven Job tatsächlich per Callstack unterbricht.
Na ja, ein brkhander verwenden wir ja,
und da das ganze noch in einer nicht ILE Umgebung läuft, mußten wir einen Gruppenjob verwenden.
Das das unter ILE einfacher/besser/anders lösbar ist ist schon klar.
So geübt mit dem GRPJOB Handling ist hier kaum noch einer.
Das müsste ebenso auch mit OPM gehen.
Oder brauchst du tatsächlich mehr als 1 Gruppenjob?
Durch SQL kommen eben Threads automatisch ins Spiel und damit sind Gruppenjobs dann Tabu.
OPM?
Die Anwender arbeiten in PGM A (menü, pgmx1, x2, x3, ... PGM A)
Dann kommt der Anruf, der brkhander ruft PGMXy,Xz... PGM A
Da bin ich ohne ILE in der Bredouille.
Ich kann den SQL Zugriff auf chain umstellen, das wäre das nächste was ich vorschlage.
aber OPM und rekursive aufrufe?
Da hab ich keine Idee
Robi
(der Rekursion im früheren leben mal mit einem komplizierten Konstrukt gelöst hat, wo das zu rufende Pgm im RekursionsFall mit crtdupobj auf a0000001, a0000002, ... kopiert wurde und die kopie statt des orginals gecalled wurde. schnell war das nicht!)