Systembefehl aus SQL heraus

[BenderD]

Das war erforderlich, als QCMDEXC noch nicht als Stored Procedure registriert war (vor Release V5R4 wenn ich mich recht erinnere). Heute ist dies nicht mehr notwendig. Die Länge sollte allerdings stimmen.

Der folgende Aufruf wird ordnungsgemäß ausgeführt.

CALL QCMCEXC('Addlible Hauser', 15)

Birgitta

... mitnichten und auch mitneffen Frau Oberlehrerin, da sind gleich mehrere Fehler, die den Erfolg vereiteln...

D*B

[KM]

...und zwar welche (außer dem Tippfehler bei QCMDEXC)?

[Anton Gombkötö]

Lieber Dieter,
hier bei mir funktioniert das auch.
Bitte erhelle uns, sage uns, warum es nicht gehen kann.
Hummeln können ja auch nicht fliegen. Gottseidank können sie auch nicht lesen. ;-)
Danke,
LG Toni

[Robi]

Ich gebe Dieter recht.
Bei mir funktioniert ein "addlible Hauser" auch nicht.

Schließlich gibt es solch eine Lib auf den wenigsten AS/400 Systemen

Robi

[Anton Gombkötö]

dass es keine Bibliothek Hauser gibt, und es diese Bibliothek wirklich nicht gibt, funktioniert das doch ordnungsgemäß?!
Ich vermute etwas intellektuell Anspruchsvolleres dahinter, schließlich ist es Dieter Bender, den verbinde ich eigentlich nicht mit Kinderkram... ;-)

[B.Hauser]

Falls es irgendjemand interessieren sollte:
QCMDEXC wurde als externe Stored Procedure in der Bibliothek QSYS2 hinterlegt.
Die Stored Procedure hat 2 Parameter:
1. CL-Befehl - VarChar(32000)
2. Länge - 15,5
Intern wird QCMDEXC aufgerufen und ausgeführt!

Die Bibliothek QSYS2 ist im Systemteil der Bibliotheksliste hinterlegt und auch bei Verwendung von SQL Naming im Default Path, so dass ein unqualifizierter Aufruf erfolgen kann.

Dadurch, dass das Original-Programm als Stored Procedure registiert wurde, kann es auch nach den gleichen Regeln wie jede andere Stored Procedure aufgerufen werden, d.h. die Anzahl der Parameter muss stimmen und die Datentypen der Parameter müssen zur Definition kompatibel sein.

Wenn man natürlich QCMDEXC mit QSYS qualifiziert aufgerufen wird, funktioniert der Aufruf nicht, da an dieser Stelle das Original-Programm aufgerufen wird (und nicht die Stored Procedure!). In diesem Fall muss der zweite Parameter mit 10 Vorkomma- und 5 Nachkommastellen angegeben werden.

Birgitta

[KM]

Falls es irgendjemand interessieren sollte:

Ich finde das schon sehr interessant. Nur was mich noch viel mehr interessiert, ist was BenderD dagegen für Einwände hat, denn bei mir funktioniert der Aufruf auch völlig problemlos.

Gibt es hier im Forum nicht jemanden, der sich immer darüber aufregt, dass andere so in Rätseln reden bzw. nur sehr spärlich mit Informationen rausrücken, so dass er seine Kristallkugel bemühen muß? Irgendwie kommt mir das hier bekannt vor.

Gruß,
KM

[Anton Gombkötö]

Vielen Dank an Birgitta, wie immer sind ihre Ausführungen sehr lehrreich und bringen uns alle ein Stück weiter, besseren Code zu produzieren.
Das schafft Dieter auch, aber man muss es ihm meistens ein bisschen aus der Nase ziehen, er ist vom Naturell her eher kein Messias, der andere überzeugen will. Aber er hat meistens eine fachlich fundierte Meinung, warum man es vielleicht nicht so und so machen sollte. Nur geizt er ein bisschen damit. ;-)

[Fuerchau]

Mich stört die Definition "VarChar(32000)
", da QCMDEXC direkt VarChar nicht unterstützt sondern nur CHAR.

Ich habe mir schon seit langem per ODBC einen "CREATE PROCEDURE QCMDEXC ..." zusammengebastelt der auch immer funktioniert hat.

Nun kommt es beim ODBC leider auf die Verwendung des Treibers an (über ADO-Objekte):
Beim MSDASQL (Standard bei ODBC-Verbindungen) reicht einfach eine "CALL XXX" um im ODBC-Serverjob ausgeführt zu werden.
Verwendet man (leider) den IBMDA400 bzw. den IBMDASQL-Provider ist ein Call in geschweifte Klammern zu setzen.
Dabei gibt es 2 Arten (wobei ich nie weiß, welcher denn nun welcher ist):

"{CALL XXX ...}"
"{{CALL XXX ...}}"

Der eine Call wird als SQL-Call ausgeführt, der andere als RMTCMD und damit eben nicht im ODBC-Job!
Lässt man die Klammern weg, fügt der Provider einfach welche ein und macht wahrscheinlich den RMTCMD.