Rückgabeparameter bei SBMRMTCMD

[BenderD]

SQL procedure geht eigentlich (fast) in jeder Kombination, dank ArdGate.

D*B

[Fuerchau]

Dafür benötige ich aber immer einen SQL-Server (muss ja nicht Microsoft sein) auf dem Zielsystem um einen SQL-Call abzusetzen.

[BenderD]

... einen Dämon (Serverdienst), der da lauscht brauchst Du eh' (REXEC für SBMRMTCMD etc.) und ICF geht auch nur, wenn da ein SNA Dienst drauf wartet, das ist nun mal Grundlage des Geschäfts.

D*B

[harkne]

Hallo zusammen, erst mal vielen Dank wieder für die vielen Lösungen, wobei ich gestehen muss dass ich weder mit einer ICF Datei (und wenn ist es schon sehr lange her und ich kann mich nicht mehr erinnern) noch mit SQL Procedure gearbeitet habe. Dass von Robi habe ich mir auch bereits überlegt allerdings mit einer DDM-File und ID somit kann Programm A Programm B mit ID aufrufen und Programm A wartet bis in der Datei die ID mit dem Ergebniswert steht. Das letztere ist zwar umständlich aber für mich verständlich, es sei denn jemand will mir das mit den Stored Procedure in SQL erklären. Das hört sich für mich gut an, habe allerdings noch nichts damit gemacht.

[BenderD]

Hallo zusammen, erst mal vielen Dank wieder für die vielen Lösungen, wobei ich gestehen muss dass ich weder mit einer ICF Datei (und wenn ist es schon sehr lange her und ich kann mich nicht mehr erinnern) noch mit SQL Procedure gearbeitet habe. Dass von Robi habe ich mir auch bereits überlegt allerdings mit einer DDM-File und ID somit kann Programm A Programm B mit ID aufrufen und Programm A wartet bis in der Datei die ID mit dem Ergebniswert steht. Das letztere ist zwar umständlich aber für mich verständlich, es sei denn jemand will mir das mit den Stored Procedure in SQL erklären. Das hört sich für mich gut an, habe allerdings noch nichts damit gemacht.

ICF File ist im Vergleich zu stored Procedure ungleich aufwändiger. Mit dem SQL Befehl CREATE PROCEDURE kann man jedes *PGM als externe stored procedure registrieren und dabei sowohl IN, OUT als auch INOUT Parameter verwenden. Aufgerufen werden diese stored Procedures dann mit dem SQL Befehl call (in einem embedded SQL Programm); macht man vorher einen connect an die remote database, dann findet der Aufruf auf einem anderen System statt. Einfach und schnell, lesbar und stabil.

@Baldur: ICF (Intersystem Communication Function, das sind doch SNA Altlasten, das würde ich doch heute keinem mehr empfehlen/zumuten.
D*B

[harkne]

Hallo Herr Bender, lokal hat das mit der Stored Procedure super funktioniert. Jetzt fehlt mir allerdings noch der Aufruf auf das ferne System. Was muss ich als connect machen ? Wenn ich über STRSQL connect angebe und Auswahl 2 (Fern) mache sehe ich trotzdem nur die lokale Datenbank.

Viele Grüße Harald

[BenderD]

... auf der clientseite braucht man einen Eintrag im remote database directory (ADDRDBDIRE ist dein Freund) und dann macht man einen connect to und ist auf dem fernen System. Im richtigen Leben macht man das dann in einem embedded SQL Programm, damit man auch an die Rückgabe drankommt. Masochisten fummeln da auch gerne mit Oops Nerv rum.

D*B

[harkne]

Hallo Herr Bender. Vielen Dank. Habe ich inzwischen gefunden. Es hilft einfach wenn man bei der Fehlermeldung auf das ferne System F1 drückt. Dort steht dann eben der ADDRDBDIRE. Funktioniert alles super und werde ich so auch verwenden Vielen Dank. Für alle die Interesse daran haben hier mal meine komplette Umsetzung.

Zunächst auf dem fernen System die Stored Procedure erstellen. In meinem Beispiel:

CREATE PROCEDURE LIB/TESTRMT2(INOUT pi CHAR ( 1), INOUT po CHAR 
( 1)) LANGUAGE CL SPECIFIC LIB/TESTRMT2 NOT DETERMINISTIC       
CONTAINS SQL EXTERNAL NAME LIB/TESTRMT2 PARAMETER STYLE GENERAL 

Das dazugehörende CL-Programm (LIB/TESTRMT2) auf dem fernen System sieht bei mir wie folgt aus

PGM        PARM(&PI &PO)                                      

DCL        VAR(&PI) TYPE(*CHAR) LEN(1)                        
DCL        VAR(&PO) TYPE(*CHAR) LEN(1)                        

IF         COND(&PI *EQ '1') THEN(CHGVAR VAR(&PO) VALUE('2')) 
IF         COND(&PI *EQ '2') THEN(CHGVAR VAR(&PO) VALUE('3')) 

ENDPGM 

Das SQL-RPG Programm auf dem lokalen System sieht wie folgt aus

d var1            s              1    inz('1')
d var2            s              1    inz(' ')
c/exec sql                                    
c+ connect to system2                         
c/end-exec                                    
c/exec sql                                    
c+ call testrmt2 (:var1, :var2)               
c/end-exec                                    
c/exec sql                                    
c+ disconnect system2                         
c/end-exec                                    
c                   eval      *inlr = *on 

Die möglichen Connections (also in diesem Beispiel system2) könnt ihr euch über WRKRDBDIRE anzeigen lassen. Wenn er dort fehlt mit ADDRDBDIRE hinzufügen.

Bei mir war das:

ADDRDBDIRE RDB(SYSTEM2) RMTLOCNAME(system2 *IP) 

Viele Grüße Harald

[Fuerchau]

Ich habe es schon länger nicht mehr ausprobiert, aber ist kein CRTSQLPKG auf dem Quellsystem an das Zielsystem mit Angabe des Quellprogrammes mehr nötig?

[harkne]

Hallo Herr Fuerchau, also bei mir hat es wie oben beschrieben funktioniert. Bei der Umwandlung habe ich keine speziellen Angaben gemacht

[BenderD]

Ich habe es schon länger nicht mehr ausprobiert, aber ist kein CRTSQLPKG auf dem Quellsystem an das Zielsystem mit Angabe des Quellprogrammes mehr nötig?

... das hängt wohl vom Programm, bzw. was man darin macht, ab.

[Fuerchau]

Ich hatte früher mal ein SQL-Programm geschrieben (allerdings in COBOL), dass per Connect auf ein beliebiges anderes System zugriff. Dies funktionierte nur, wenn man per CRTSQLPKG das interne SQLPKG auf das Zielsystem übertrug. Es kam sogar zum Abbruch, wenn die "Signatur" des SQLPKG's nicht identisch war.
Nun mag die RPG-Runtime da ein wenig mehr tun. Schließlich macht die ja auch einen automatischen STRCMTCTL falls der noch nicht läuft, was COBOL auch nicht macht.
Prüfe doch mal bitte, ob du auf dem Zielsystem ein *SQLPKG mit dem Namen deines Programmes (ggf. in QGPL) findest und wenn ja, mach einen PRTSQLINF davon.