COBOL Subroutine mittels SQL aufrufen

[ChookaA]

Zwischen die einzelnen Parameter müssen Kommata:

Call Schema.Subroutine('PARAM1', 'PARAM2', 'PARAM3');

Hast Du die Subroutine auch mit dem SQL-Befehl CREATE OR REPLACE PROCEDURE als stored procedure registriert?

Birgitta

Hallo, also es soll ein Teil eines Programms, also nur eine bestimme Sequenz in einem Cobol Hauptprogramm angesprochen werden, ob da "Subroutine" der richtige Begriff kann ich nicht sagen, soweit habe ich es jedenfalls verstanden. Und Nein dieser "Teilbereich" ist nicht mit "CREATE OR REPLACE STORED PROCEDURE" versehen, die Frage ist ob er das muß oder ob es auch irgendwie anders geht ..

[B.Hauser]

Ich bin jetzt nicht der Cobol-Programmierer, aber ...
kann die "Subroutine" von außerhalb des Cobol-Programms, also von einem anderen Cobol-Programm aufgerufen werden?
Wenn nein, dann kannst Du diese "Subroutine" auch nicht über SQL aufrufen.
In diesem Fall musst Du aus der "Subroutine" ein Programm machen und dieses mit CREATE OR REPLACE als Stored Procedure registrieren.

Sofern diese "Subroutine" von außen aufgerufen werden kann, musst Du diese "Subroutine" zunächst als SQL Stored Procedure registrieren (also mit CREATE OR REPLACE PROCEDURE).
Wenn Du die Registrierung über ACS (Access Client Solutions - Schemas) durchführst bekommst Du auch eine ganz gute Bedienerführung.
Erst dann wenn die "Subroutine" als Stored Procedure mit Input und Output-Parametern registriert ist, lässt sie sich auch aus einer SQL-Umgebung aufrufen.

Birgitta

[Fuerchau]

Eine COBOL-Subroutine kann von außen nicht direkt aufgerufen werden.
COBOL hat nicht dieselbe Unterstützung bzgl. der Prozeduren wie ILERPG.

SQL erlaubt jedoch, jedes beliebige Hauptprogramm per Call mit Parametern aufzurufen.
Diese sind in COBOL dann in der Linkage-Section passend zu definieren und abzufragen.

Aber besser ist es auf jeden Fall, eine SQL-Prozedur als externe Prozedur mit passenden Aufrufkonventionen zu erstellen. Diese externe Prozedur darf dann wiederum ein anderes Hauptprogramm gerne aufrufen. Das nennt man dann Wrapper-Programm.

Um eine Prozedur eines Programmes aufzurufen, bedarf es für SQL der Registrierung einer Prozedur in einem Service-Programm.
Dies ist auch in COBOL möglich, wenn man ein COBOL-Modul erstellt und dieses dann in ein Service-Programm verpackt.

Die typische Subroutiene in COBOL wird mit PERFORM aufgerufen und entspricht im RPG der EXSR-Anweisung. Dahinter verbirgt sich nur leider kein CALL sondern ein GOTO mit einem Return, der wie ein "go to ." und einem passenden "Alter Label to proceed to" wirkt.
Daher ist ein Perform auch nicht rekursiv aufrufbar.

[ChookaA]

Eine COBOL-Subroutine kann von außen nicht direkt aufgerufen werden.
COBOL hat nicht dieselbe Unterstützung bzgl. der Prozeduren wie ILERPG.

SQL erlaubt jedoch, jedes beliebige Hauptprogramm per Call mit Parametern aufzurufen.
Diese sind in COBOL dann in der Linkage-Section passend zu definieren und abzufragen.

Aber besser ist es auf jeden Fall, eine SQL-Prozedur als externe Prozedur mit passenden Aufrufkonventionen zu erstellen. Diese externe Prozedur darf dann wiederum ein anderes Hauptprogramm gerne aufrufen. Das nennt man dann Wrapper-Programm.

Um eine Prozedur eines Programmes aufzurufen, bedarf es für SQL der Registrierung einer Prozedur in einem Service-Programm.
Dies ist auch in COBOL möglich, wenn man ein COBOL-Modul erstellt und dieses dann in ein Service-Programm verpackt.

Die typische Subroutiene in COBOL wird mit PERFORM aufgerufen und entspricht im RPG der EXSR-Anweisung. Dahinter verbirgt sich nur leider kein CALL sondern ein GOTO mit einem Return, der wie ein "go to ." und einem passenden "Alter Label to proceed to" wirkt.
Daher ist ein Perform auch nicht rekursiv aufrufbar.

Beim Versuch der Erstellung einer externen Stored Procedure mit LANGUAGE COBOL hat es im ersten Effekt daran gescheitert das ich nicht mehr als 29 Parameter festlegen konnte. Zum Aufruf des Programmes sind mindestens 49 IN Parameter notwendig. Dies ist auch unabhängig von der Größe des Datenfeldes bei 29 war Schluß .. Liege ich da richtig oder ist der Layer 8 das Problem?

[B.Hauser]

Wie hast Du denn versucht die Routine zu definieren?
Mit irgendeinem Tool?

Lt. der aktuellen Dokumentation sind selbst bei der Registrierung von OPM Programmen 254 Parameter und bei ILE programms 2000 Parameter zulässig.

Und auf welchem IBM i Release bist Du überhaupt?

Birgitta

[ChookaA]

Wie hast Du denn versucht die Routine zu definieren?
Mit irgendeinem Tool? --> Nativ mit SQL auf dem System I Navigator

Lt. der aktuellen Dokumentation sind selbst bei der Registrierung von OPM Programmen 254 Parameter und bei ILE programms 2000 Parameter zulässig. --> ja ist mir auch rätselhaft

Und auf welchem IBM i Release bist Du überhaupt? --> System I Navigator Version 7 Release 1 / Windows 10 Pro ..

[Fuerchau]

Dann poste mal die SQL-Definition der Prozedur/Funktion und ebenso die Linkage Section deines COBOL-Programmes.

[ChookaA]

Dann poste mal die SQL-Definition der Prozedur/Funktion und ebenso die Linkage Section deines COBOL-Programmes.

--************************************************** ******************
--SP TEST
CREATE OR REPLACE PROCEDURE SCHEMA_NAME.STORED_PROCEDURE_NAME(
IN //...52 Parameter...//
)
DYNAMIC RESULT SETS 1
LANGUAGE COBOL
SPECIFIC SCHEMA_NAME."STORED_PROCEDURE_NAME"
DETERMINISTIC
MODIFIES SQL DATA
CALLED ON NULL INPUT
EXTERNAL NAME 'SCHEMA_NAME/COBOL_PGM_NAME'
PARAMETER STYLE GENERAL
PROGRAM TYPE SUB;

[ChookaA]

wieso kann ich in einer externen Procedure nur maximal 29 Parameter deklarieren? Gibt es da eine SYS Einstellung?

[Fuerchau]

"The maximum number of parameters can be further limited by the maximum
number of parameters allowed by the language."

Ändere dein Programmtyp auf CBLLE, dann kannst du im SQL COBOLLE angeben. Ggf. erlaubt dir SQL dann mehr Parameter. COBOL braucht im Gegensatz zu RPG da keine Konvertierung.

Allerdings finde ich persönlich schon mehr als 10 Parameter bedenkenswert.

[ChookaA]

Also grundsätzlich kann ich COBOL Programme per SQL aufrufen, das habe ich mit einem Testprogramm auch getestet. Funktioniert wunderbar, erzeugt eine Spool Datei mit einem Parameterwert den ich mir auch dann auch anzeigen lassen kann.

Das mit dem Programmtyp probiere ich mal. Da es aber um mehrere COBOL Programme geht die ich damit ansprechen will wäre das ja schon fast ein komplettes Update auf die Sourcen ..

Gibt es einen SYS-Wert der die Parameteranzahl limitieren könnte??

[ChookaA]

"The maximum number of parameters can be further limited by the maximum
number of parameters allowed by the language."

Ändere dein Programmtyp auf CBLLE, dann kannst du im SQL COBOLLE angeben. Ggf. erlaubt dir SQL dann mehr Parameter. COBOL braucht im Gegensatz zu RPG da keine Konvertierung.

Allerdings finde ich persönlich schon mehr als 10 Parameter bedenkenswert.

Also ich habe jetzt das SQL Statement mit "LANGUAGE COBOLLE" initialisiert und jetzt nimmt die DB2 alle 51 Parameter. *freu Jetzt noch auf der Gegenseite das COBOL Programm umkonvertieren?