View Full Version : Runsql aus CL-Programm funktioniert nicht mehr
Hallo,
wir haben ein CL-Programm aus dem ein RUNSQL aufgerufen wird, um eine Datei zu löschen. Dieser Job läuft einmal monatlich währen des laufenden Betriebes. Bis voriges Monat hatten wir damit keine Probleme, doch jetzt geht gar nix mehr. Bekommen ein LOCKWaiting obwohl wir am Programm nichts geändert haben.
Folgender CL-Code:
*10772*/ CHGVAR VAR(&STMT) VALUE('DELETE FROM LEABS1')
/*10772*/ RUNSQL STMT(&STMT)
/*10772*/ CPYFRMIMPF FROMSTMF('/home/updbs1.dat') +
TOFILE(LEA/LEABS1) MBROPT(*ADD) +
RCDDLM(*CRLF) STRDLM(*NONE) FLDDLM(&TAB)
/*11468*/ CHGVAR VAR(&STMT) VALUE('DELETE FROM LEA/LEABS1 +
WHERE BACASTELLE > 09999')
/*11468*/ RUNSQL STMT(&STMT)
CHGVAR VAR(&MSG) VALUE('Update LEABS1 durchgef +
ührt, Sicherung LEABS1SAV')
SNDPGMMSG MSG(&MSG)
Hat irgendjemand eine Idee???
LG
Da hängt dann wohl noch jemand anders an der Datei.
Prüfe mal per WRKOBJLCK LEABS1 *FILE => F6, wer das denn ist.
Da hängt dann wohl noch jemand anders an der Datei.
Prüfe mal per WRKOBJLCK LEABS1 *FILE => F6, wer das denn ist.
Danke für den Tipp, aber das war mir schon klar, und es sind auch mehrere User auf dem File. Nur verstehe ich dann nicht, wieso funzt das unter V5R4 und unter V6R1 nicht mehr??? Hast Du dafür eine logische Erklärung?
LG
delete ohne where clause entscheidet sich zeitweilig für einen clrpfm, ich würde es mal mit einer Meldung Software defekt versuchen
Ist RUNSQL überhaupt ein System-Befehl?
Ich kenne nur RUNSQLSTM und finde auch RUNSQL nicht auf meiner Maschine.
Sollte der Befehl aus einem Fremdprodukt kommen, sollte der Hersteller kontaktiert werden, vielleicht wird der Befehl unter 6.1 einfach nicht mehr (richtig) unterstützt.
Birgitta
... bei der defekt Meldung würde ich dann natürlich auf STRQMQRY verweisen, damit da nicht noch jemand auf die Idee kommt, dass es an einem "Fremdprodukt" liegt.
D*B
Ist RUNSQL überhaupt ein System-Befehl?
Ich kenne nur RUNSQLSTM und finde auch RUNSQL nicht auf meiner Maschine.
Sollte der Befehl aus einem Fremdprodukt kommen, sollte der Hersteller kontaktiert werden, vielleicht wird der Befehl unter 6.1 einfach nicht mehr (richtig) unterstützt.
Birgitta
Ja hast recht, habe vorher nicht nachgeschaut. Einfach nur das Programm angeschaut. Ist ja auch eine riesen Anwendung, die wir da am Laufen erhalten müssen.
Werde mal nachfragen, ob die was neueres für uns haben. Ist nämlich das einzige Teil, was wir aus diesem Produkt noch im Einsatz haben.
Danke für eure Hilfe.
LG
Andreas
'Langsam am verzweifeln mit RTC und RDp'
Da du den SQL-Befehl ja kennst, ersetze das einfach durch einen QM-Query (STRQM) und ersetze den Befehl mit STRQMQRY.
Da du den SQL-Befehl ja kennst, ersetze das einfach durch einen QM-Query (STRQM) und ersetze den Befehl mit STRQMQRY.
... und habe dann dasselbe Problem, denn STRSQL macht nix anderes - und das Problem kommt von der Datenbank, die sollte nämlich den CLRPFM nur in Erwägung ziehen, wenn sie die erforderliche Sperre kriegt!
Eventuell hilft auch ein Workaround und die DB läss sich narren mit delete from ... where 1= 1
D*B
Da du den SQL-Befehl ja kennst, ersetze das einfach durch einen QM-Query (STRQM) und ersetze den Befehl mit STRQMQRY.
Also mein Kollege und ich habe das jetzt mal genauer untersucht. Ursprünglich war das ein Befehl eines Drittanbieters. Irgendwann in grauer Vorzeit(2002), wird sind ja alle schon Dino's, haben dann ehemalige Kollegen was eigenes geschnitzt. Diese Lösung entspricht im großen und ganzen dem, was Hr. Fuerchau geschrieben hat. D.h. das sollte so funktionieren.
Das mit der Sperre ist aber ein ganz anderes Problem. Denn nachdem wir das auf unsererm Testsystem ausprobiert haben, hat es dann auf einmal funktioniert. Der einzige Unterschied zu früher (vor V6R1) ist der, dass das Programm um ein vielfaches länger für diesen einfachen delete benötigt. Dieses länger liegt leider im Minutenbereich.
lg
Andreas