-
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 = 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
-
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
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
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
-
Zitat von dschroeder
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.
-
Zitat von Fuerchau
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
-
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.
-
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
-
By Kirsten Steer in forum Archiv NEWSblibs
Antworten: 0
Letzter Beitrag: 17-01-03, 11:57
-
By MKnoll in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 19-11-02, 15:21
-
By areichelt in forum NEWSboard SAP
Antworten: 2
Letzter Beitrag: 24-02-02, 16:44
-
By MichaZ in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 06-08-01, 21:54
-
By tomski in forum IBM i Hauptforum
Antworten: 0
Letzter Beitrag: 14-12-00, 21:16
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks