Alternative zu DTAQ

[meini]

Hallo,

wir benötigen eine Alternative zu DataQueues für die Nachritenübertragung von RPG-Programmen zu einem Java-Server. Leider reichen die 64512 Bytes pro Message nicht immer aus und eine bereits erfolgte Minimierung des Datenaufkommens hat das Problem nur hinaus geschoben. Für den umgekehrten Weg ist die DTAQ völlig ausreichend.

Derzeit schreiben mehrere RPG-Programme in die gleiche Queue, deshalb wäre eine Kommunikation über einen USRSPC ungleich aufwändiger hinsichtlich der Synchronisation der Zugriffe usw.

Unsere letzte Idee war die Verwendung von Sockets für die Datenübertragung. Leider müsste dann für jede gestartete Anwendung ein Port geöffnet werden. Zusätzlich wird je ein weiterer Port benötigt, um mit diesem Port zu kommunizieren. Da die Anzahl der Nutzer derzeit nicht abzuschätzen ist, wäre es möglich, dass uns hier irgendwann die Ports ausgehen ...

Habt ihr vielleicht noch andere Ideen, wie man das anstellen könnte?

Gruß
Klaus

[Fuerchau]

Nimm eine SQL-Tabelle mit einem LOB-Feld (BLOB, CLOB) und einem eindeutigen Keyfeld (Identity oder Long-Zähler).

Schreibe die Daten in die PF mit Schlüssel und sende den Schlüssel an die DTAQ (als Dispatcher oder Wecker).

Der Empfänger liest die DTAQ, holt sich die Daten per SQL aus der Tabelle und löscht den Eintrag.

Was anderes fällt mir auf die Schnelle auch nicht ein.

[BenderD]

... in Paketen senden! Eine einfache Implementierung kann man sich in meiner Open Source ArdGate ansehen.

D*B

Hallo,

wir benötigen eine Alternative zu DataQueues für die Nachritenübertragung von RPG-Programmen zu einem Java-Server. Leider reichen die 64512 Bytes pro Message nicht immer aus und eine bereits erfolgte Minimierung des Datenaufkommens hat das Problem nur hinaus geschoben. Für den umgekehrten Weg ist die DTAQ völlig ausreichend.

Derzeit schreiben mehrere RPG-Programme in die gleiche Queue, deshalb wäre eine Kommunikation über einen USRSPC ungleich aufwändiger hinsichtlich der Synchronisation der Zugriffe usw.

Unsere letzte Idee war die Verwendung von Sockets für die Datenübertragung. Leider müsste dann für jede gestartete Anwendung ein Port geöffnet werden. Zusätzlich wird je ein weiterer Port benötigt, um mit diesem Port zu kommunizieren. Da die Anzahl der Nutzer derzeit nicht abzuschätzen ist, wäre es möglich, dass uns hier irgendwann die Ports ausgehen ...

Habt ihr vielleicht noch andere Ideen, wie man das anstellen könnte?

Gruß
Klaus

[Robi]

Bei uns malt der Java Job den Gui Bilschirm.
Damit er schon mal anfangen kann, bevor die letzte Info aus dem grünen PGM ermittelt wurde, schreiben wir mehrere Happen. In der Datendefinition gibt es ein 'ENDE-DER-DATEN' Kennzeichen. Daran erkennt das Java Pgm, das nix mehr kommt.
Umgekehrt genauso, wobei da selten mehr als ein Happen kommt.
Robi

ok, die Happen heisen Pakete und Dieter war schneller

[meini]

Vielen Dank für eure Vorschläge.

Der Vorschlag mit dem CLOB wäre wohl der einfachste, nur habe ich Zweifel ob ich das so umsetzen darf. Ich musste ja sogar schon um Varchar-Felder in der Datenbank kämpfen :/

Wenn unser Java-Spezialist aus dem Urlaub zurück ist, werden wir evaluieren, welcher Ansatz für ihn am Besten wäre.

[Fuerchau]

Solange nur ein Empfänger und Sender auf der DTAQ liegt ist Paketierung kein Problem.
Sind mehrere Sender beteiligt kommen die Pakete durcheinander es sei denn man macht während der Paketierung einen ALCOBJ und hinterher eben einen DLCOBJ.

Hängen mehrere Empfänger auf einer DTAQ (Verteilung auf mehrere Prozesse), dann ist Paketierung nicht möglich, da ja die DTAQ im Roundrobbin-Verfahren gelesen wird bekommt der 1. Empfänger den 1. Satz und der 2. Empfänger den 2. Satz.

Wenn ihr euch für eine PF entscheidet ist ja ggf. auch auf die DTAQ zu verzichten.

Und was so neumodischen Kram wie VARCHAR angeht, wieso nehmt ihr dann schon Java ?

PS:
Und was VARCHAR bzw. CLOB angeht, bei der DTAQ werden in deinem Fall immer 64KB (Satzlänge) übertragen egal ob voll oder nicht, bei VARCHAR nur das was da ist.

[BenderD]

... wer sagt denn sowas? Schau dir mal die Paketierung in ArdGate an. (BTW: dann würde das komplette TCPIP auch nicht funzen...)

D*B

Solange nur ein Empfänger und Sender auf der DTAQ liegt ist Paketierung kein Problem.
Sind mehrere Sender beteiligt kommen die Pakete durcheinander es sei denn man macht während der Paketierung einen ALCOBJ und hinterher eben einen DLCOBJ.

Hängen mehrere Empfänger auf einer DTAQ (Verteilung auf mehrere Prozesse), dann ist Paketierung nicht möglich, da ja die DTAQ im Roundrobbin-Verfahren gelesen wird bekommt der 1. Empfänger den 1. Satz und der 2. Empfänger den 2. Satz.

Wenn ihr euch für eine PF entscheidet ist ja ggf. auch auf die DTAQ zu verzichten.

Und was so neumodischen Kram wie VARCHAR angeht, wieso nehmt ihr dann schon Java ?

PS:
Und was VARCHAR bzw. CLOB angeht, bei der DTAQ werden in deinem Fall immer 64KB (Satzlänge) übertragen egal ob voll oder nicht, bei VARCHAR nur das was da ist.

[meini]

Solange nur ein Empfänger und Sender auf der DTAQ liegt ist Paketierung kein Problem.

Genau hier liegt ja das Problem. Es gibt mehrere Sender-Programme und mehrere Java-Threads als Empfänger.
Gundsätzlich sollte es aber möglich sein, dass die Fragmente anhand einer eindeutigen ID und einer Sequenznummer über die Threads hinweg wieder zusammen gesetzt werden.

Und was so neumodischen Kram wie VARCHAR angeht, wieso nehmt ihr dann schon Java ?

Aus dem einfachen Grund, weil RPG nativ keine WebSockets handeln kann. Das alles selbst zu implementieren wäre dann doch ein wenig zu viel Overhead
Aber es scheint Besserung in Sicht zu sein: letztlich hab ich sogar eine Tabelle mit NULL-fähigen Feldern erstellt

[BenderD]

Aber es scheint Besserung in Sicht zu sein: letztlich hab ich sogar eine Tabelle mit NULL-fähigen Feldern erstellt

... auch das geht schon seit mehr als zehn Jahren.

[Fuerchau]

Wenn du mehrere Threads als Empfänger hast, würde ich das dann auf einen Dispatcher-Thread umstellen, also nur noch einen Empfänger.
Der stellt dann die Pakete wieder zusammen und leitet dann das vollständige Paket an eine interne Thread-Queue weiter.
Diese nehmen sich dann wieder nach Roundrobbin die vollständigen Einträge aus der Queue.

[BenderD]

... dieweil die Worker Threads im allgemeinen nicht stateless sind, bietet sich da eher ein Worker (-Thread) pro Client an...