SQL Stored Procedure verschwindet

[florian]

Hallo zusammen !
Habe auf unserer iSeries (V5R3) eine SQL-Stored Procedure mithilfe von WRKMBRPDM geschrieben, und erstelle die Prozedur dann anschliessend mit RUNSQLSTM. Problem: Das Erstellen funktioniert nur mit COMMIT(*NONE), alle anderen Parameter führen zu "Rollback erforderlich". Selbst bei COMMIT(*NONE) tauchen im Joblog nacheinander die Fehler CPF5035, CPF5036 und CPF5029 auf. Fehlermeldung: Datenzuordnungsfehler in Teildatei SYSPARMS, Fehlercode 20, ungültiger Nullwert in Feld PARMNAME. Danach kommen noch weitere Fehlermeldungen mit anderen Feldern aus SYSPARMS. Nach dem Erstellen mit COMMIT(*NONE) kann ich die Prozedur trotzdem verwenden (wird von einer Web-Anwendung verwendet) und z. B. über den Navigator testen. Sobald ich mich allerdings mit der interaktiven Session, in der ich das RUNSQLSTM ausgeführt habe, abmelde, "verschwindet" die Prozedur wieder (Rollback ?). Kann mir jemand helfen ? Was mache ich falsch bzw. was kann ich tun ?
Danke und Gruß, Florian

[Fuerchau]

1. Solltest du die Fehler in der Prozedur beheben, da liegt offensichtlich ein Definitionsfehler vor.
2. Die Datei SYSPARMS wird im Systemjournal aufgezeichnet, erfordert also einen Commit, auch wenn du mit COMMIT(*NONE) arbeitest.

[florian]

Ich kann aber leider nicht erkennen, was an dieser Proc falsch definiert sein soll...

0001.00 CREATE PROCEDURE AHLWEBLIB/ARTIK008
0002.00 (IN I_LAGER DEC (4, 0),
0003.00 IN I_FIRMA DEC (3, 0),
0004.00 IN I_DATUM DEC (8, 0))
0005.00 LANGUAGE SQL
0006.00 DYNAMIC RESULT SETS 1
0007.00 BEGIN
0008.00 DECLARE X CHAR(1);
0009.00 DECLARE RETCUR CURSOR WITH RETURN FOR
0010.00 SELECT * FROM QTEMP/ARTIK002;
...
0042.00 OPEN RETCUR;
0043.00 DROP TABLE QTEMP/ARTIK002;
0044.00 END

Ist es vielleicht ein Problem, ein CREATE TABLE und ein DROP TABLE in QTEMP innerhalb einer Prozedur zu machen ?

Gruss, Florian

[Fuerchau]

Du kannst natürlch keine Tabelle löschen, für die noch ein Cursor offen ist.
Wo ist denn der "Create Table" ?
Damit die Prozedur erstellt werden kann, muss die Tabelle natürlich vorhanden sein.
Was willst du mit der Tabelle in QTEMP ?

[florian]

Das sind ja gleich eine ganze Menge Fragen. Also:
Das ich die Tabelle "eigentlich" noch nicht an der Stelle droppen kann, habe ich mir schon gedacht. Das Problem ist, die Prozedur wird von einer ASP.NET-Webanwendung aufgerufen, und wann die die Verbindung kappt und den Cursor schließt, ist mir noch nicht so ganz klar, da die Ereignissteuerung hier auch nicht ganz einfach ist. Damit das Ganze überhaupt funktioniert, gibt es innerhalb der Prozedur auch einen SQLEXCEPTION Handler. Das DROP TABLE habe ich auch schon weggelassen, ändert aber nichts an dem ursprünglichen Fehler.
Der CREATE TABLE kommt direkt nach dem BEGIN. Für die Erzeugung der Prozedur erstelle ich die Tabelle in QTEMP unmittelbar vor dem RUNSQLSTM, damit der Compiler die Datei findet.
In QTEMP packe ich das Ganze (=meine Arbeitsdateien), da ich nicht verhindern kann/will, daß die Prozedur parallel von mehreren Usern aufgerufen wird, und ich dadurch in getrennten Arbeitsbereichen arbeite. Wenn ich eine echte physische Tabelle nehme, müsste ich die vorher clearen, und würde damit u. U. das frisch erstellte Ergebnis eines anderen Users zerschießen.
Das kann aber doch alles nicht die Ursache dafür sein, daß die Prozedur nach Beendigung der interaktiven Session, die sie erstellt hat, verschwindet ? Oder ist QTEMP hier wirklich das Problem ? Was wäre denn eine Alternative an der Stelle ?

[Fuerchau]

ACH JAAA !
Du erstellst eine Prozedur in QTEMP.
QTEMP ist aber für jeden Job separat.
Also, wenn du dich abmeldest ist deine QTEMP weg, also auch deine Prozedur.

Aber hier ist dein Ansatz falsch.
Wenn du per Select ein Resultset erstellst, dann ist dieses doch temporär.
Wozu benötigst du also eine temporäre Tabelle ?!

[florian]

Nee, das ist es leider nicht. Die Prozedur erstelle ich schon in einer echten Lib (CREATE PROCEDURE AHLWEBLIB/ARTIK002 = Bibliothek AHLWEBLIB), nicht in QTEMP. Sonst wäre das Problem klar.
Allerdings erstellt meine Prozedur eine Arbeitsdatei in QTEMP, da das Resultset bzw. die Verarbeitung für "Nur-SQL" zu komplex ist. Ich glaube auch nicht, dass der Inhalt der Prozedur wirklich ein Problem ist, da ähnliche Prozeduren bereits produktiv sind. Auch dort werden in QTEMP Arbeitsdateien erstellt etc., alles kein Problem.
Ich glaube, mein Problem basiert wirklich auf den CPFs, die beim Erstellen der Prozedur im Joblog auftreten. Ich vermute hier eher einen OS-Bug, der dazu führt, daß diese Prozedur nicht korrekt im Systemkatalog angelegt werden kann.

[Fuerchau]

Irgendwie verstehe ich da was nicht.

Was führt dein RUNSQLSTM denn aus ?

Prüfe mal, ob die Prozedur mit dem Namen nicht schon existiert, bereinige ggf. per "drop procedure" noch mals.

Wenn alles nichts hilft, ggf. ein RCLSTG *DBXREF.

[TARASIK]

Hallo Florian,
ich würde die Ptfs SI23415 und SI22645 installieren.

[florian]

Hallo zusammen !

Also, das RUNSQLSTM führt die "CREATE PROCEDURE" - Anweisung aus. Wenn es die Prozedur vorher schon gab, wird sie auch automatisch gelöscht - das kann ich dem Joblog noch vor den CPFs entnehmen.

Und ein RCLSTG DBXREF kostet mich wieder das Wochenende Ist ja produktiv, die Maschine... Runterfahren bzw. eingeschränkter Modus ist nur Sonntags drin...

Aber ich werde mich mal schlau machen, was sich hinter den PTFs von Tarasik verbirgt. Ich vermute, wie gesagt, ja auch eher einen OS-Bug an der Stelle.

Werde dann wieder berichten, ob es was gebracht hat. Habe sowieso einige Probleme mit Stored Procs auf der Maschine, kann zum Beispiel auch keine über den Navigator erstellen. Deswegen auch der Weg über RUNSQLSTM.

Gruss, Florian

[TARASIK]

Hallo Florian,
wegen rclstg *dbxref. Der Command läuft je nach System zwischen 10 und 20 Minuten.
Das mit dem erstellen im Navigator. Da fehlt auf dem Pc bestimmt das Servicepack Iseries Access SI23492