Call Programm vs. Service-PGM

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

[BenderD]

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.

... sowas ähnliches wie Mehrfach Aktivierungen bekommt man, wenn man alle globalen (statefull) Variablen in eine Datenstruktur legt (ich nenne die this) mit dim MAXINST. Dann macht man eine Procedure getHandle, die eine int zurückgibt (Constructor lässt grüßen); diese Procedure gibt dann den Index auf ein freies Element des arrays mit und muss bei jedem Aufruf als erster Parameter mitgegeben werden. Wer ein wenig damit gespielt hat, kann dann das Array auch dynamisch machen etc....

D*B