Pgm. Aufruf mit Parm. auf zwei AS400

[bechert]

Hallo Forum
hier mein Szenario.
AS400 A mit Warenwirtschaft soll auf AS400 B aus der Fibu
den aktuellen Saldo des Kunden ermitteln und auf AS400 A
anzeigen. Das Programm zur Saldenermittlung läuft auf
AS400 B. Kann mir jemand einen Lösungsansatz nennen?
Die Maschinen sind mit LWL verbunden.
Gruß Christian

[Fuerchau]

Am einfachsten:
Auf Maschine B horcht ein Programm auf einer DTAQ.
Auf Maschine A wird eine Anfrage an eine Remote-DTAQ (zu Maschine B) gestellt, die vom dortigen Programm beantwortet wird.
Am besten eignet sich eine Keyed-DTAQ um über die Schlüssel die Partner eindeutig zu identifizieren.
Vorteil: über Timeout kann maximal auf die Antwort gewartet werden.

Am kompliziertesten (auch wenn andere anderer Meinung sind):
Per WRKRDBDIRE die Datenbank der Maschine B registrieren.
Per CONNECT und SELECT direkt den Saldo ermitteln.
Kleiner Nachteil: keine Timeout-Funktion.

[KM]

... oder Du verwendest DDM-Dateien und greifst damit direkt auf die Dateien auf Maschine B zu.

Gruß,
KM

[Frank Hildebrandt]

Über eine stored Procedure läßt sich das auch realisieren.

[bechert]

Hallo erstmal Danke für eure Hinweise.
Ich habe es erstmal so gelöst. DDM-File mit User;Pgm.-Namen; to String(Maschine A); back String(Maschine B). WAWI Maschine A schreibt Satz in DDM-File und ruft mit runrmtcmd Salden-Pgm., mit PARM User, auf Maschine B auf in back String stehen dann meine info's.
Am einfachsten wäre es natürlich wenn man per DDM direkt
auf den Saldo zugreifen könnte aber diese Information muss
immer neu gerechnet werden.
Gruß Christian

[holgerscherer]

... oder Du verwendest DDM-Dateien und greifst damit direkt auf die Dateien auf Maschine B zu.

Wo wir grade beim Thema sind : habe gelegentlich mit DDM unter V5R4 Probleme - wenn diese Maschine auf eine PF zugreift, die auf einer V5R2-Maschine liegt... die DDM-Routinen loopen gelegentlich mit hoher CPU-Last. Hast das jemand auch beobachten können?

-h

[DVE]

Folgender Vorschlag:
Per DDM in Datei auf Maschine B schreiben.
An Datei auf Maschine B hängt ein Trigger, das z.B. bei UPDATE ausgeführt wird.
Wenn also auf Maschine A Programm A per DDM auf Maschine B schreibt, wird "interaktiv" das Triggerprogramm (Programm B) aufgerufen und sobald das Triggerprogramm B fertig ist, kannst du mit Programm A das Ergebnis von Programm B lesen.
Damit sparst du dir RUNRMTCMD etc. .
Die Datei kannst du z.B. so stricken, dass die Parameter für Programm B und die Rückgabewerte für Programm A als Felder definiert sind.


Gruß
DVE

[GeorgG]

Die benötigten Dateien als DDM File auf Maschine A erstellen
und das Pgm. zur Saldenermittlung auf maschine A laufenlassen ?
spart rmtcmd und Wartezeiten

[DVE]

Die benötigten Dateien als DDM File auf Maschine A erstellen
und das Pgm. zur Saldenermittlung auf maschine A laufenlassen ?
spart rmtcmd und Wartezeiten

Vielleicht missverständlich geschrieben ??
Programm A schreibt über DDM-File in Datei auf System B. Auf System B wird das Triggerprogramm ausgeführt. Da das ganze wie ein CALL ist, wartet Programm A bis Programm B fertig ist.
Und damit, braucht man kein RUNTMTCMD o.ä. .


Gruß
DVE

[bechert]

Hallo DVE, danke für den Tip. Nur für mein Verständnis Trigger-
PGM löst bei Insert aus und ermittelt den Saldo. Jetzt muss ich nur noch das Ergebniss zurückbekommen. Der Satz wird aber noch von der Write Anweisung gesperrt. Brauche ich
jetzt eine 2. DDM-File für meine Ergebnisse?
Gruß Christian

[Fuerchau]

Am besten verwendest du einen Lese-Trigger.
Der kann dann den gelesen Puffer um die gewünschte Information ergänzen.

Beim Insert-Trigger benötigst du anschließend noch einen Lese-Befehl, da der Trigger nur die Daten in die gewünschte Datei schreiben kann.

[BenderD]

@Baldur: und beim Lese Trigger brauchst du einen vorherigen insert, damit du was zum lesen hast; und wenn irgend jemand auf die harmlose Idee kommt, den Schmonz zu lesen, dann....

Das wird ja immer toller, ursprünglich ging es um einen synchronen Aufruf eines vorhandenen Programmes auf einer anderen Maschine, jetzt haben wir schon mehrere DataQs und unterschiedliche Varianten von Triggern im Einsatz (ähnliches kann man auch im Naturpark Blockheide-Gmünd besichtigen), obwohl es für die ursprüngliche Antwort vorhandene Funktionen gibt. lest euch noch mal das posting von Frank Hildebrand durch, da brauchts einen deklarativen Eintrag im Repository, maximal einen Eintrag im Remote Database Directory (wenn man ihn noch nicht hat) und dann kann man das per SQL dirkt aufrufen, inklusive komplettem Errorhandling und Wiederanlauf...

Dieter Bender

Am besten verwendest du einen Lese-Trigger.
Der kann dann den gelesen Puffer um die gewünschte Information ergänzen.

Beim Insert-Trigger benötigst du anschließend noch einen Lese-Befehl, da der Trigger nur die Daten in die gewünschte Datei schreiben kann.