Setsamer sporadischer Fehler, MCH5804 + SQL0913

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

[Fuerchau]

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.

[Robi]

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.

[Fuerchau]

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.

[Robi]

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!)

[Fuerchau]

Auch ILE funktioniert rekursiv nur im Service-Programm.
Nun denn, auch dafür gibts eine Lösung.
Aber:
Da du ja schon 7.1 hast kannst du die Programme auch schnell per CVTRPGSRC in ILE überführen.
Allerdings löst das dein Rekursionsproblem nicht direkt.

Hier kannst du dann per ILE und Prozedur-Pointer einen "Callback" initiieren.
D.h., du legst in QTEMP einen USRSPC an und besorgst dir den Pointer dazu.
Nun kannst du, wenn PGMA läuft, einen Prozedurpointer im USRSPC ablegen.
Dein BRK-Handler kann nun die Prozedur mit den benötigten Parametern ganz einfach rekursiv aufrufen.

Alternative 2:
Du kannst eine DTAQ an die DSPF hängen und in deinen Satzformaten per INVITE die Tastatur freigeben und per FRCDTA die Sofortausgabe erzwingen.
Somit kannst du per WRITE deine Daten ausgeben.
Dann legst du dich per QRCVDTAQ schlafen (ggf. per Timeout für andere Aktionen).
Drückt der User nun irgendeine Taste kommt der QRCVDTAQ zurück mit der Kennung Taste gedrückt und du kannst das Satzformat per READ nun auslesen. Dein Programm wird nun nicht geblockt.

Dein BRK-Handler braucht nun nur noch in diese DTAQ zu schreiben und nichts mehr aufrufen.
Beim Beenden löst der QRCVDTAQ nun mit den gesendeten Daten aus.

[Robi]

Auch ILE funktioniert rekursiv nur im Service-Programm.

und mit 'das 1 Pgm läuft mit ACTGRP *new, alle anderen mit *Caller'

auch schnell per CVTRPGSRC in ILE überführen

nur Pgmme die sehr gravierend geändert werden 'dürfen' in ILE umgesetzt werden.

Du kannst eine DTAQ an die DSPF hängen und in deinen Satzformaten per INVITE die Tastatur freigeben und per FRCDTA die Sofortausgabe erzwingen.

Das ist schon so, aber für andere spielchen, selbe Pgm aber andere User.
In diesem Fall geht das nicht

Ich werde das SQL Pgm durch ein LF und einen Chain ersetzen

Danke
Robi