Wie verwendet man CLI server mode?

[BenderD]

Hallo liebes Forum,
ich bin auf das Thema "CLI server mode" gestoßen (worden). Das ist für mich ganz neu, denke ich jedenfalls.

Habe ich folgende Dinge richtig verstanden?

1. Wenn ich embedded SQL im RPG verwende, wird das SQL im interaktiven Job des SQL-Programms ausgeführt?
2. Wenn ich den CLI server mode aktiviere, wird das SQL in separaten Jobs ausgeführt und liefert das Result an das anfordernde RPG-Programm. Für mich als Programmierer ist das aber völlig transparenent. Es geht dabei nur um das Verfahren im Hintergrund. Ist das so?
3. Das CLI Verfahren ist performanter bzw. ressourcenschonender als das Standardverfahren?
4. Wir möchten SQL Funktionen aus SYSTOOLS einsetzen, die eine JVM benötigen. Wenn wir nicht in jedem interaktiven Job eine JVM haben möchten, ist das CLI Verfahren eine Lösung?

Sind die obigen Aussagen bzw Fragen richtig? Sind wir da überhaupt auf dem richtigen Weg? Oder lohnt sich die Beschäftigung mit dem Thema gar nicht?

Vielen Dank im Voraus.

Dieter

@1: richtig
@2: fast richtig, Probleme gibt es im Mix Server/nicht Server
@3: fast richtig, der zusätzliche Job kostet Ressourcen, die allerdings nicht zur interaktiven Workload zähle. Kann bei bestimmtem Lizenzmodellen Vorteile haben, bei anderen aber auch Nachteile.
@4: ganz falsch. Das kann sogar zum doppeltem Ressourcenverbrauch führen, da man jetzt zwei Jobs hat, in denen man eine JVM starten kann. Zudem lässt sich die JVM in den Serverjobs nicht kontrollieren, da man nicht weiß, wer die zuerst gestartet hatte.

Ich würde die Finger von solchen SQL Funktionen lassen, die gibt es nur, um den Hardware Umsatz anzukurbeln. Das skaliert selbst dann nicht, wenn man das versucht asynchron zu entkoppeln, da sie nur multithreaded ausgeführt werden können, wenn man jeweils eine separate Connection verwendet und dann ist man wieder am Asugangspunkt.

Was machen die denn so wertvolles, dass man über diesen Murks überhaupt nachdenken muss?

D*B

@Baldur: wenn man die im Java verwendet, laufen die wieder in den Serverjob der Connection und starten da noch eine JVM.

[dschroeder]

Vielen Dank! Also lasse ich das Thema CLI dann doch lieber weg. Zu deiner Frage, was die SYSTOOLS Funktionen so wertvolles machen: Wir verwenden z.B. die HTTPGETCLOB Funktion. Die holt die Daten eines Webservices und gibt sie als CLOB zurück. Wenn ich das manuell nachbaue, benötige ich sicherlich einiges an Code. Mit der Funktion habe ich nur einen Einzeiler in meinem RPG-Programm, um die Webservice Daten abzurufen.

[BenderD]

Vielen Dank! Also lasse ich das Thema CLI dann doch lieber weg. Zu deiner Frage, was die SYSTOOLS Funktionen so wertvolles machen: Wir verwenden z.B. die HTTPGETCLOB Funktion. Die holt die Daten eines Webservices und gibt sie als CLOB zurück. Wenn ich das manuell nachbaue, benötige ich sicherlich einiges an Code. Mit der Funktion habe ich nur einen Einzeiler in meinem RPG-Programm, um die Webservice Daten abzurufen.

Der Preis dafür eine JVM zu starten ist allerdings immens und im Java dürfte das auch ziemlich elementar zu erledigen sein und dann kann man das über Appserver4RPG (oder einen eigenen Mechanismus) ebenfalls als Einzeiler aus RPG aufrufen - ohne in jedem Job eine JVM zu starten.
Dazu kommen ja noch die Nebenwirkungen, die daraus resultieren, dass eine vorher bereits gestartete JVM ja nicht funktionieren muss (Classpath etc.).

D*B

[dschroeder]

Wir haben uns vor ein paar Jahren dafür entschieden, in RPG keine Javaklassen mehr zu embedden. Das heißt, wir benötigen in unseren Jobs keine "eigene" JVM. Die JVM von den IBM-Funktionen sollte deshalb störungsfrei arbeiten können.
Das schöne an den IBM Funktionen ist eben, dass sie bereits verfügbar sind und ich gar nichts weiter machen müsste.

[Fuerchau]

Das kannst du ja auch tun.
Allerdings würde ich hier eben auch den Weg der DTAQ-Services verwenden.
Ein RPGle sendet an die DTAQ den Webrequest, der DTAQ-Server führt diesen aus und schickt die Antwort an den Requestor zurück.
Da die DTAQ in der Satzlänge keine CLOB aufnehmen kann ist die Alternative auch ein USRSPC, der wie Shared Memory funktionieren kann und bis 16MB aufnimmt.
Der Requestor legt einen USRSPC und DTAQ mit Jobnr an und schickt die Anforderung an den Server.
Dieser bearbeitet die Anforderung, legt die Antwort in den USRSPC und schickt einen Wecker an die Job-DTAQ. Der Requestor kann die Antwort nun aus dem USRSPC auslesen.
Ein paar Aufräumaktionen (DTAQ/USRSPC löschen) und man ist fertig.

Man kann sich auch einen Pointer auf den USRSPC holen. Das funktioniert dann wie Shared Memeory und ist auch am schnellsten.

Wie gesagt, die DTAQ-Server kann man dann skalieren um parallele Abfragen zu erlauben.

[BenderD]

Einspruch: der DataQ Server kann immer nur eine Anforderung nach der anderen bearbeiten, das skaliert auch nicht.

D*B

[Fuerchau]

Einspruch abgelehnt;-).
An eine DTAQ kann man mehrere Reader anhängen, die im RoundRobin die Anforderungen auslesen, beantworten und sich wieder hinten dranhängen.
Über PJE's kann man dann festlegen, wieviele parallele Jobs man haben möchte und falls sich mal einer verabschiedet oder verabschieden muss, ob dann automatsch neue gestartet werden.

Auf diesem Wege archiviere ich seit 100 Jahren mittels Spoolüberwachung (DTAQ an OUTQ) parallel viele Spools da ein Job alleine dies nicht schafft. Ich komme hier mit 5 aus.

[BenderD]

... kann man was draus machen (gefühlte Ewigkeit her, dass ich sowas selber gemacht habe).

[dschroeder]

Wenn wir uns für eine Entkoppelung der interaktiven Sitzung und der Webservice-Aufrufe entscheiden sollten, denken wir auch eine DTAQ Lösung. Das Segmentieren der Results, die 64K übersteigen können, ist ein bisschen aufwendig. Deshalb haben wir auch schon an eine Lösung gedacht, in der wir die Daten in eine Streamfile schreiben. USRSPC ist da aber vielleicht noch schneller.

Nochmals danke für alle Hinweise.

[Fuerchau]

Interprozesskommunikation mit USRSPC und Pointer ist das schnellste wo gibt, gefolgt von DTAQ sofern die nicht per Force auf die Platte schreiben muss.

[andreaspr@aon.at]

Wir haben auch schon solche Anforderungen gehabt und wir arbeiten sehr viel mit DTAQs.
Allerdings verwenden wir für die Schnittstelle einfach nur Tabellen.
Über die DTAQs werden dann nur die ID übermittelt und fertig.

Also
1. PGM A --> sendet ID 4711 and DTAQ
2. PGM B liest ID 4711 ein.
3. PGM B führt WebService Request durch und speichert Ergebnis in Tabelle
4. Rückantwort an DTAQ von PGM A
5. PGM A kann mit Daten weiter arbeiten.

Wenn du willst, kann ich dir ein fertiges Code Beispiel schicken die dir die Kommunikation via DTAQ zeigt.

lg Andreas

[dschroeder]

Danke Andreas. Mach dir bitte erstmal keine Mühe. Wir sind noch nicht sicher, welchen Weg wir gehen. Am liebsten wäre es mir, wenn wir auf die Entkoppelung ganz verzichten könnten. Ich möchte aber gerne einen Plan B in der Hinterhand haben, falls Performanceprobleme auftreten.