View Full Version : SQL-Prozedur mit cpytoimpf-Aufruf hängt
Ich filtere in einem SQL-Skript Daten in ca. 250Ausgabedateien aus und kopiere diese anschließend per cpytoimpf als csv ins IFS. Da ich natürlich nicht 250cpytoimpf-Anweisungen programmieren möchte, mache ich das dynamisch über eineStored Procedure, die ich 250 Mal aufrufe. An diese Prozedur übergebe ich Quelle und Ziel des Kopiervorgangs. Daich in der Prozedur direkt keine CL-Anweisung ausführen kann, rufe ich einCL-Programm aus der Prozedur auf, das den cpy ausführt. Wie hier im Forum schonhäufiger besprochen wurde, ist der cpytoimpf nicht threadsafe, so dass imJoblog die Meldung ‚CPD000D - Befehl *LIBL/CPYTOIMPF nicht sicher für Job mitmehreren Nachrichten‘. Aber dabei steht auch, dass ‚Die Verarbeitung desBefehls wird fortgesetzt.‘
Allerdings hängt sich mein Job tatsächlich auf. Der Cpy wirdausgeführt, aber dann stehen plötzlich beide Threads auf Wait:
Gesamt- Aux Ausführungs-
Thread Status CPU I/O priorität
0000011E TIMW 20,324 106013 20
000006E0 THDW 0,013 100 20
Es scheint so, als ob der eine auf der anderen wartet. Aberwarum?
Gibt es eine Möglichkeit zu verhindern, dass die Prozedurbzw. das CL in mehreren Threads läuft?
- Lt. JobD steht der Parameter ‚Mehrere Threadszulassen‘ auf *NO
- Der Systemwert QQRYDEGREE steht auf *NONE
- OS-Release ist V6R1M0
- Die Optionen ‚Unfenced‘ und ‚disallow parallel‘scheint es in einer Prozedur nicht zu geben
Hat einer eine Idee, warum sich mein Job aufhängt?
Oder wie ich Multi-Threading vermeiden kann?
Oder gibt es eine Alternative zu cpytoimpf, die Threadsafeist?
Eine Idee nicht, aber den Befehl über ein CLP aus SQL heraus aufzurufen ist schon etwas gegen SQL!
CPYTOIMPF verwendet selber nun auch wieder SQL und da wird es schon Probleme mit den Ressourcen geben.
Dies tiefer zu analysieren halte ich für kontraproduktiv. Rufe deine "Prozedur" doch einfach mit den benötigten Parametern direkt auf.
Wenn die Parameter wiederum das Ergebnis eine Selects ist, schreibe ein ILERPG drumrum.
Nicht alles was geht ist auch möglich;-).
Warum ist das gegen SQL? Die Syntax (
LANGUAGE CL + external Name) bietet SQL ja an, um ein CL-Programm direkt aufzurufen. Und ich möchte natürlich alle Schritte des Datenexports nacheinander in einem Skript aufrufen.
Die Prozedur mit diesen Optionen rufe ich dann direkt im Skrip mit Call auf. Klar kann ich in RPG ein Serviceprogramm mit einer RPG-Funktion schreiben, dass dann wiederum den cpytoimpf ausführt. Aber habe ich nicht wieder das gleiche Problem, wenn ich die RPG-Funktion aus einer SQL-Funktion aufrufe? Habe ich dann nicht wieder mehrere Threads?
RobertMack
30-10-19, 09:48
Ich würde erstmal alle Kopieraufträge in eine DTAQ schreiben und diese danach abarbeiten lassen.
Bei entsprechender Masse (oder ähnlichen Aufträgen) auch gleich über ein eigenes Subsystem mit Lauschprogramm (AJE).
Alleine das Problem der Threadness ist zu lösen. Da CPYxxxIMPF das nicht gewährleistet und eben hängenbleibt, sollte ich dieses nicht innerhalb einer Prozedur aufrufen.
Ich habe nicht gesagt, dass du den CPY-Aufruf in eine ILERPG-Prozedur verpacken sollst, die wiederum eine SQL-Prozedur ist.
Ich weiß ja nicht wie du deine SQL-Prozedur verwendest, aber an Stelle von SQL sollst du eben dein CLP direkt aufrufen.
Wenn nun die Parameter deines Aufrufes das Ergebnis eines Select's sind, schreibe ein ILERPG dass den Select mittels Fetch ausliest und dann den CPY respective das CLP direkt mit den Ergebnisvariablen aufruft.
Alleine das Problem der Threadness ist zu lösen. Da CPYxxxIMPF das nicht gewährleistet und eben hängenbleibt, sollte ich dieses nicht innerhalb einer Prozedur aufrufen.
Ich habe nicht gesagt, dass du den CPY-Aufruf in eine ILERPG-Prozedur verpacken sollst, die wiederum eine SQL-Prozedur ist.
Ich weiß ja nicht wie du deine SQL-Prozedur verwendest, aber an Stelle von SQL sollst du eben dein CLP direkt aufrufen.
Wenn nun die Parameter deines Aufrufes das Ergebnis eines Select's sind, schreibe ein ILERPG dass den Select mittels Fetch ausliest und dann den CPY respective das CLP direkt mit den Ergebnisvariablen aufruft.
... mir kräuseln sich zwar alle Nackenhaare bei diesem Design, aber hast Du mal set current degree = 'NONE' versucht?
D*B
@RobertMack, an eine asynchrone Verarbeitung habe ich auch schon gedacht, allerdings per sbmjob. Da ich die Dateien im ifs nach dem Copy aber noch weiter verarbeite, brauche ich bei asynchroner Verarbeitung eine Steuerung, über die ich herausfinde, ob alle Copys durch sind. Erst dann darf ich mit dem nächsten Schritt weitermachen. Alles machbar. Aber unschön.
@FUERCHAU: Auch das wäre eine alternative Lösung auch wenn ich eigentlich ohne RPG-Programmierung auskommen wollte.
@BenderD: das Design ist einfach und schlank und übersichtlich. So wie es sein soll. Nur dass der Job sich aufhängt )-:
Wenn ich set current degree = 'NONE' ausführe, kommt die Fehlermeldung:
QL-Status: 01623 Anbietercode: -1530 Nachricht: [SQL1530] Anweisung SET CURRENT DEGREE nicht vollständig aktiviert. Ursache . . . . : Parallelverarbeitung ist auf dieser Maschine nicht aktiviert, da die Systemkomponente DB2 Symmetric Multiprocessing nicht auf dem System installiert ist.
Also warum hat mein Job 2 Threads, wenn Parallelverarbeitung auf der Maschine eh nicht möglich ist?
Weil Threads erlaubt sind, aber die SQL-Parallelverarbeitung nicht installiert ist.
Nun, wenn du RPG nicht magst kannst du ja auch CLP nehmen.
Einen QMQRY mit Ausgabe in Datei und per CLP die Datei verarzten und den CPY aufrufen.
Es muss nicht immer ILERPG sein, COBOL ginge ja auch noch...
habe ich mich wohl unglücklich ausgedrückt: es ist nicht so, dass ich RPG nicht mag. Ganz im Gegenteil, RPG ist gut. In meinem Projekt sollte ich komplett ohne Programmierung auf der AS400 auskommen. Stattdessen sollten nur mit im ACS-SQL-Skript-Editor erstellte Skripte im IFS des Kunden eingespielt werden.
Klar, durch das CL-Programm mit dem cpytoimpf musste ich das schon mal aushebeln. Wäre aber schön gewesen, wenn es eine Ausnahme geblieben wäre
Tja, es geht eben nicht alles mit SQL.