Pgm. Aufruf mit Parm. auf zwei AS400

[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.

[Rincewind]

Kann mich da meinem Vorredner nur anschliessen...

Soweit es geht vermeide ich Trigger, da es sich bisher IMMER auch anders (einfacher, verständlicher) lösen ließ.

Wir haben hier 5 Iseries Stehen, alle mit unabhängigen Datenbanksystem verschiedenen Typs (Shop, Fibu, Altanwendung, Neuanwendung etc. etc.) und der Zugriff dazwischen läuft nur noch über SQL (problemlos, solange nicht ein Irrer auf die Idee kommt eine Iseries im Betrieb auszuschalten) oder FTP (Massendatenübertragung).

Schönen Gruß
Rince

P.s. DDM Files funktionieren auch nicht auf jedem Release problemlos miteinander und auch nicht bei jeder Verbindungsart
Trigger "verschlucken" sich schonmal bei zuvielen Paralellen Zugriffen