Call Programm vs. Service-PGM

[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.

[dschroeder]

OK, vielen Dank für die Info.

Dieter

[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

[Fuerchau]

Bei korrektem Design der Schnittstellen und der BinderLanguage ist ein erneutes Binden tatsächlich nicht erforderlich.
Schließlich muss ich ja bei einem Betriebssystemwechsel/-update auch meine Programm nicht neu binden um die diversen System-Servicceprogramme (ILE-Laufzeit, C-Funktionen usw.) weiter zu verwenden.
Und was die Parameter angeht, so kann ich obigem Verfahren nur zustimmen (das gibts ja bei Systemfunktionen auch), dass ich neue Parameter als "optional" am Ende anfüge, so dass alle alten Programme mit der selben Schnittstelle ohne neues Binden bedient werden können.

[AG1965_2]

Stimmt; Dieters Methode ist sehr praktisch. Man kann sich da das Serviceprogramm im Speicher wie die Instanz einer Java-Klasse vorstellen und mit Gettern und Settern Variablen, die man sonst bei jedem Aufruf übergeben müsste, nur einmal setzen. Die sitzen im Speicher des Serviceprogramms. Ich hab' halt nur eine "Instanz", aber das reicht mir für meine Zwecke auch völlig.
Z.B. habe ich bei unserem XML-Modul die Notwendigkeit, 4 Keyfelder zu kennen, die setze ich mit einem SetKey(Feld1,Feld2,Feld3,Feld4). Das verringert die Anzahl der Parameter bei den restlichen Funktionen deutlich und macht die Programme viel lesbarer.