Call Programm vs. Service-PGM

[Fuerchau]

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.

[malzusrex]

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]

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

[Robi]

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]

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

[BenderD]

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

[Fuerchau]

Mit korrekter BindaryLanguage ist ein Rebind nicht erforderlich!
Das ist zumindest meine Feststellung.

[BenderD]

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

[AG1965_2]

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.

[dschroeder]

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

[Fuerchau]

Das ist nun mal Geschmackssache.
Ob viele Objekte oder wenige tun zur Laufzeit nicht so weh (s.o.).
Interessant wird es dann eher bei der Verwaltung "gemeinsamer" Ressource, also Variablen/Dateien, die global definiert sind. Dies geht bei mehreren Programmen natürlich nicht (z.B. Filehandler).
Auch das Thema ACTGRP's ist nicht zu vernachlässigen.
Serviceprogramme können eine eigene ACTGRP haben, somit auch eine eigene SQL-Schicht.
Sollen alle einzelnen Service-Programme in der selben ACTGRP laufen so muss man dies explizit bei der Umwandlung ja angeben.
Hat ein SRVPGM mal *CALLER, kann es aus verschiedenen ACTGRP's aufgerufen werden und ist dann jeweils aktiv, also nicht gemeinsam genutzt.

Beim richtigen Design der Anwendung macht für jede externe Funktion ein eigenes Programm eben weniger Sinn.

Und das Signaturproblem ist ja lösbar.

[BenderD]

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

Wenn man die Parameterschnitsstelle ändert, dann muss man neu binde, sonst knallt es auch bei einem Export!!!

Wenn man nur eine Procedure exportiert, dann kann man auch ein Programm draus machen und das über einen Prototyp aufrufen, das ist einfacher und deswegen besser.

Hat man mehrere exportierte Procedures in einem Modul, dann können die untereinander über shared Data kommunizieren, was die Parameterschnittstellen lesbarer und einfacher macht. (Denke doch mal an ein Datenzugriffsmodul mit read und update Funktionalität...)

Für die Softwareverteilung (Softwarehaus mit Versionen) sind weniger Einheiten im Deployment einfacher.

... auch Dieter