[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Jan 2012
    Beiträge
    1.102

    Wie verwendet man CLI server mode?

    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

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Da verwechselst du 2 Dinge:
    a) CLI sind SQL-C-API's
    b) JVM ist Java

    Embedded SQL in ILE/RPG ist immer die einfacherer Lösung, zumal dies ja sprachlich und vom Compiler voll integriert ist.
    CLI mit den ganzen C-API's (wofür es erst mal keine Templates, also PR-Definitionen gibt) ist i.W. eben für C, also noch noch nicht mal C++ gedacht.
    Hier kann man sicherlich einiges mehr machen als mit embedded SQL, allerdings muss man alles alleine machen. Angefangen von SQLEnvironment über SQLConnect, SQLPrepare, SQLBindParam, ...., bis SQLDisconnect.
    Besonders problematisch sind die sog. Handles, die nicht automatisch aufgeräumt werden.
    Allerdings kann man hier über das SQLEnvironment den Server-Mode im separaten Job initiieren.
    Aber was soll dir das dann bringen?

    Also alles in allem voll dynamisch!

    Die SQL-Funktionen aus Systools kann man gerne verwenden, den JVM-Kram regelt dann sowieso die Datenbank und CLI hilft dabei ja auch nicht.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Vielen Dank für die Antwort, Baldur. Eigentlich geht es bei der ganzen Problemanalyse nur darum, dass es bei uns Bedenken gibt, die SYSTOOLS Funktionen, die in Java implementiert sind, massenhaft (also z.B. in jedem interaktiven Job) zu verwenden. Wir haben festgestellt, dass eine JVM den Speicherbedarf eines Jobs um ca. 60 MB steigert. Eben weil die Verwendung von z.B. HTTPGETCLOB eine JVM hochzieht. Und die JVM bleibt ja solange am Leben, wie der Job läuft.

    Das heißt, wenn wir 1500 interaktive Sitzungen haben und jede startet eine VM, müsste der Hauptspeicherbedarf um 1500 mal 60 MB steigen. Das sind 90 GB. Unser Hauptspeicher ist zwar fast ein TB groß, aber trotzdem könnte es ja sein, dass die 90 GB (die ja eigentlich unnötig sind - IBM hätte das ja auch in C realisieren können) uns nennenswert Performance kosten.

    Deshalb arbeiten wir an Ideen, wie wir die Hauptspeicherbelastung durch die vielen VMs begrenzen können. Möglichst ohne große Umprogrammierung.

    Im IBM Developer Forum habe ich die Aussage erhalten, dass bei einem Anwender Performanceprobleme auftraten, nachdem viele VMs gestartet wurden. Die Lösung war dort anscheinend, den Hauptspeicher aufzurüsten. Das geht bei uns nicht mehr. 1 TB ist bei unserer Maschine die physische Grenze.

    Vielleicht passiert auch gar nichts schlimmes, wenn wir die VM in jeden Job packen. Es ist nur ein gewisses Risiko, das wir gerne vermeiden möchten.

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Zumal dann die Java-Jobs die meiste Zeit nur rumdümpeln.

    Da helfen dann aber so alte Wege wie DTAQ's weiter.
    Man schaffe sich einen zentralen Service, der auf einer DTAQ horcht und jede Anfrage mit entsprechenden Aufrufen und auf einer Antwort-DTAQ (Job-spezifisch) zurücksendet.
    Da die Anfragen ja nicht von allen Dialogen gleichzeitig erfolgen, kann man das dann auch schön skalieren, da auf einer DTAQ beliebig viele Jobs horchen können.
    D*B hat da auf seiner Seite bzgl. zentralisierter Java-Aufrufe eine fertige OpenSource-Lösung.
    Ich denke dies kann man ebenso auch für andere Zwecke entfremden oder die Systools-SQL's führt man dann halt in Java aus.
    "Application Server für RPG" http://www.bender-dv.de/index.html
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von dschroeder Beitrag anzeigen
    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.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  6. #6
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    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.

  7. #7
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von dschroeder Beitrag anzeigen
    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
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  8. #8
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    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.

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  10. #10
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Einspruch: der DataQ Server kann immer nur eine Anforderung nach der anderen bearbeiten, das skaliert auch nicht.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  11. #11
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  12. #12
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... kann man was draus machen (gefühlte Ewigkeit her, dass ich sowas selber gemacht habe).
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

Similar Threads

  1. Zend Server auf IBM i - Kann nicht auf Server zugreifen
    By msost in forum IBM i Hauptforum
    Antworten: 7
    Letzter Beitrag: 04-11-15, 15:56
  2. Debug im 132er mode ist weg
    By Robi in forum NEWSboard Programmierung
    Antworten: 15
    Letzter Beitrag: 25-06-15, 15:30
  3. Antworten: 2
    Letzter Beitrag: 12-03-14, 21:09
  4. Adresse wird bereits verwendet ! (TCP/IP)
    By WOKO in forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 13-08-02, 17:24

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •