[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    May 2002
    Beiträge
    1.121

    Call Programm vs. Service-PGM

    Hallo Gemeinde,

    ich bin gerade mit meinen Kollegen am diskutieren, was schneller und eleganter ist.
    Bisher wurde meistens ein Call auf ein PGM gemacht, oder den selben Code immer in jedes Programm über nommen. Ich würde jetzt aber lieber auf Funktionen umstellen die ich in Service-PGMs ablege.
    bisher
    PHP-Code:
    c                   Call      'MYPGM'               
    c                   Parm                    Wert1   
    c                   Parm                    Wert2   
    c                   Parm                    Wert3   
    c                   Parm                    Ergebnis 
    Und ich will auf
    PHP-Code:
    c                   Eval      Ergebnis MyFunktionWert1Wert2Wert3
    Die MyFunktion muss natürlich in den D-Zeilen noch angelegt werden.

    Ich bin ja der Meinung das die Geschichte über Service-PGM besser und schneller ist als der Call.
    Liege ich damit richtig? Oder macht das kein Unterschied?

    Gruß
    Ronald

  2. #2
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... Geschwindigkeit (und Overhead) kannst Du getrost vernachlässigen, ein call auf ein offenes Programm ist ähnlich schnell, wie der call einer aktivierten Procedure.
    Die Vorteile sind in erster Linie im Design zu sehen. Ein Serviceprogramm kann mehrere Entry Points (exportierte Procedures) haben und für die Procedures können lange Namen verwendet werden.

    Diese Vorteile überwiegen bei richtiger Vorgehensweise die Nachteile der komplexeren Programm Erstellung.

    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/

  3. #3
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Der eigentliche CALL ist von der Performance absolut egal, ob Programm oder Procedure.
    In beiden Fällen wird ein Instruction-Pointer verwendet.
    Entscheidend ist da eher die "Initialisierungszeit" eines Programmes bzw. Serviceprogrammes.
    Jede konstante Verknüpfung zu einem Programm/Procedure wird beim ersten Aufruf des Programmes initialisiert.
    Hierzu wird das Objekt gesucht und der Einsprungspunkt ermittelt.
    Je mehr Call's also im Programm stecken, desto mehr Objekte müssen ermittelt werden.

    Bei Prozeduren ist es ein wenig anders.
    Es kommt i.W. darauf an, wieviele verschiedene Serviceprogramme denn durch die Prozeduren benötigt werden.
    Das ermitteln des Serviceprogrammes dauert genauso lange wie beim OPM-Programm.
    Die Prozedurpointer werden dann allerdings über die exportierte Liste der Funktionen an Hand des internen Indexes zur Verfügung gestellt, also 1. Funktion = Index 1, 2. Funktion = Index 2, usw.
    Dies erklärt im Übrigen auch, dass bei Neuerstellung eines Service-PGM's ohne BindaryLanguage mit eigener Signatur, sich diese Indizes auf Grund der Sortierung nach Namen verschieben können.

    Stellst du also viele Funktionen über diverse OPM-Programme zur Verfügung dauert der Init letztlich länger als bei vielen Funktionen über wenige Serviceprogramme.
    Ein paar Microsekunden kannst du per "CALL VARIABLE" gewinnen, da dann der Pointer erst beim ersten Aufruf besorgt wird. Solange sichdie variable dann nicht ändert bleibt der Pointer erhalten.
    Das selbe kannst du mit Dieters "dynamschen Prozeduraufruf" erreichen.
    Allerdings verlierst du dann Informationen für DSPPGMREF.

    In der Gesamtbetrachtung einer Anwendung sind das Stellschrauben, die dir beim Programmstart letztendlich Microsekunden bringen werden.
    Da sind eher andere Initialisierungen wie laden von Anwendungsparametern, Initialisierungen mit ungünstegen SQL's usw. viel entscheidender.

    Anwendungsdesign mit Serviceprogrammen und Prozeduren bringen ansonsten erhebliche Vorteile.
    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

  4. #4
    Registriert seit
    May 2002
    Beiträge
    1.121
    Danke euch beiden für die Informationen.

    Ich werde mich hier wohl mal durch setzen und das über Serviceprogramme lösen.
    Wenn ich erst einmal mit 2,3 Funktionen angefangen habe, werden von selbst schon noch andere dazu kommen. Muss halt nur etwas Überzeugungsarbeit leisten.

    Gruß
    Ronald

  5. #5
    Registriert seit
    Aug 2006
    Beiträge
    2.073
    Hallo,
    wir haben hier schon vor 20 Jahren in Cobol fast nur mit Modulen gearbeitet. Wenn man eine vernüftige Benamsung der Module hat, gibt es in meinen Augen nichts schöneres als mit solchen "Bausteinen" zu arbeiten, da die Hauptprogramme dadurch kürzer und effektiver werden, und man im Fehlerfall zum einem die erprobten Module nicht mehr prüfen muß und zum anderen mit der Änderungen eines Modules einen Fehler in vielen Programmen beheben kann.
    Selbst die Dateioperationen fürs Öffnen, Schreiben etc. haben wir ausgelagert.
    Muss natürlich jeder für sich selbst entscheiden.
    Hatte jetzt den Fall das mich eine Firma nach 15 Jahren nochmals wegen einer Programmmodifikation ansprach, und ich aufgrund der sehr übersichtlichen Programmstruktur sofort wieder in der Lage war das Programm zu modifizieren.
    Setzte allerdings damals ne Menge Vorarbeit (und harte Diskussionen) voraus. Aber es hat sich gelohnt.

    GG
    GG

  6. #6
    Registriert seit
    Jun 2001
    Beiträge
    1.973
    Auch wir setzen das seid Jahren erfolgreich ein
    Die Lesbarkeit und der Wartungsaufwand werden deutlich geringer.
    Wenn mehr als einer programmiert sollten allerdings klare Namensregeln vorhanden sein.
    ( es mach kein Sinn ein Pgm das einen/mehrere Wert(e) / Satz(e) holt immer mit GET anfangen zu lassen, wenn danach ALLE Pgmme GET* heißen)
    Auch ist es (aus Bequemlichkeit uund für die Akzeptanz bei den anderen ) wichtig, Umwandlungsroutinen zu haben die das Binden der Objekte automatisch mit machen.
    Auch über das verwenden der Bindersprache sollte man sprechen.
    Bei uns ist es so, das beim Releasewechsel beim Kunden möglichst wenig Objekte getauscht werden dürfen. Auch das kann man dabei beachten.
    Robi
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

  7. #7
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Wir schreiben neue Programm fast ausschließlich als Serviceprogramme. Für uns sind die wesentlichen Vorteile:
    - sprechende (lange) Programmnamen
    - problemlose Verwendung im free-Format
    - In der Regel gute Erkennbarkeit von Input und Rückgabewerten
    - Verwendbarkeit in logischen Ausdrücken

    Über die Geschwindigkeit würde ich mir keine Gedanken machen. Bei uns ist da kein Unterschied bemerkbar.

    Wir verfolgen übrigens die Strategie, in jedes Serviceprogramm nur genau eine exportierte Procedure zu packen. Wenn man mehrere Procedures in einem Serviceprogramm hat und die Parameterschnittstelle einer Procedure verändert, verändert man damit die Signatur des gesamten Serviceprogramms. Das heißt, es sind alle Programme betroffen, die irgendeine Prozedur aus dem Serviceprogramm verwenden. Vielleicht gibt es dafür aber auch eine andere Lösung.

    Dieter

  8. #8
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von dschroeder Beitrag anzeigen
    Wir verfolgen übrigens die Strategie, in jedes Serviceprogramm nur genau eine exportierte Procedure zu packen.
    Dieter
    ... dann kann man sich die Komplexität bei der Programm Erstellung sparen und einfach nur für die Programme Prototypen verwenden, damit geht dann außer Verwendung im logischen Ausdruck alles.

    Am Rande sei vermerkt: eine Parameterschnittstelle ändert man nicht, dann fügt man eine neue Prozedur hinzu. Was sich mir auch nicht erschließt, ist die verbreitete Angst vor einem rebind, kriegt ihr das vom Gehalt abgezogen?

    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/

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Mit korrekter BindaryLanguage ist ein Rebind nicht erforderlich!
    Das ist zumindest meine Feststellung.
    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
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Mit korrekter BindaryLanguage ist ein Rebind nicht erforderlich!
    Das ist zumindest meine Feststellung.
    ... und mit CHGPF LVLCHK(*NO) und CHGLF LVLCHK(*NO) braucht man nach Dateiänderung nicht kompilieren!
    Das ist meine Feststellung, empfehle ich aber trotzdem nicht - aus gutem Grund, wie ich meine...

    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
    Oct 2013
    Beiträge
    171
    Die Empfehlung der IBM lautet aber schon, eher wenige, größere Serviceprogramme zu haben als viele kleine.
    Ein Serviceprogramm mit einer einzigen Funktion drin hat nicht mehr viele Vorteile gegenüber einem normalen Call, den ich ja genau so prototypisieren kann und im verwendenden Programmcode dann nicht von einem Aufruf einer Funktion in einem Serviceprogramm unterscheiden kann. (Wozu auch.)
    Da sollte man seine Nase vielleicht (nochmal?) in die Handbücher stecken. Dann wird man merken, dass auch das Versionieren möglich ist.
    Wir haben die Serviceprogramme nach Zweck unterteilt. Es gibt eins für IFS-Funktionen, eins für XML-Dinge, etc., und kommen bislang mit einer fix vergebenen Signatur durch. Neue Funktionen kommen einfach immer ans Ende der Bindersprachensource.
    Wenn neue (logischerweise optionale) Parameter dazu kommen, wird in der Source mit %PARMS() und %PARMNUM(Parametername) abgefragt, ob er übergeben wurde.

  12. #12
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Es mag ja sein, dass man mit Binder-Language, Versionierung, %parms usw. die Signaturprobleme bei Serviceprogrammen, die mehrere Exporte haben, lösen kann. Ich habe jedoch noch nicht verstanden, wo der Nachteil liegt, wenn man pro Serviceprogramm nur eine Procedure exportiert. Damit vermeidet man die Signaturprobleme ja prinzipbedingt. Es gibt ja immer nur eine Signatur.

    Dieter

Similar Threads

  1. 4Call - Die erfolgreiche Call-Center Lösung
    By Kirsten Steer in forum Archiv NEWSblibs
    Antworten: 0
    Letzter Beitrag: 17-01-03, 12:57
  2. AS/400 Service Functions
    By MKnoll in forum IBM i Hauptforum
    Antworten: 4
    Letzter Beitrag: 19-11-02, 16:21
  3. Remote Function Call -> SAP
    By areichelt in forum NEWSboard SAP
    Antworten: 2
    Letzter Beitrag: 24-02-02, 17:44
  4. Service Direktor
    By MichaZ in forum IBM i Hauptforum
    Antworten: 2
    Letzter Beitrag: 06-08-01, 22:54
  5. IBM Service Suite
    By tomski in forum IBM i Hauptforum
    Antworten: 0
    Letzter Beitrag: 14-12-00, 22:16

Berechtigungen

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