View Full Version : 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
c Call 'MYPGM'
c Parm Wert1
c Parm Wert2
c Parm Wert3
c Parm Ergebnis
Und ich will auf
c Eval Ergebnis = MyFunktion( Wert1: Wert2: Wert3)
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
... 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
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.
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
KingofKning
07-11-13, 13:39
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
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
dschroeder
07-11-13, 16:56
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
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
Mit korrekter BindaryLanguage ist ein Rebind nicht erforderlich!
Das ist zumindest meine Feststellung.
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