-
Die Regel 2 ist programmtechnisch unnötig.
Ohne Bindarylanguage werden die Exporte sowieso sortiert.
Mit Bindarylanguage bestimmt man die Reihenfolge selber.
Regel 1 sollte man entschärfen und an Stelle von Programm "Modul" setzen.
Ein Programm/Serviceprogramm kann durchaus eine beliebige Anzahl von Modulen enthalten.
Auch wenn das Ladeverhalten vielseitig diskutiert wurde gilt trotzdem folgendes (außer bei dynmischem Binden á la GetProcPtr von Dieter):
Beim Laden eines Serviceprogrammes/Programmes werden sämtliche statischen Adressverweise auf externe Programme direkt per "GetSystemPtr" aufgelöst und somit auch die benötigten externen Programme geladen bevor die erste Zeile Code ausgeführt wird (INZ-Direktive).
Je mehr externe Verweise benötigt werden, desto länger halt das Laden.
Sicherlich wird ggf. nicht das gesamte Objekt geladen sondern nur der Datenteil, der die Verweise enthält.
Dadurch ergibt sich, dass wenige große Serviceprogramme schneller geladen sind als viele viele kleine.
Das initialisieren der ProcedurePointer erfolgt dann nur noch an Hand der Verweisliste im bereits geladenen Objekt.
Auch wenn es sich nur im Bereich von Millesekunden bewegt, die Summe über viele tausende Aufrufe macht es dann doch aus.
Nicht umsonst verwaltet das System selber eine zentrale Verweistabelle, die bei BS-Installation initialisiert wird und einige Tausend benötigte Programmverweise auf Q-Programme enthält um genau diese Initialisierungszeiten zu sparen. Durch das Einspeicherkonzept erfolgen die Aufrufe dann tatsächlich extrem schnell.
-
... es geht selber bei den Experten wüst durcheinander, sobald das Thema Binder Language ins Spiel kommt.
Ein einfaches Szenario, warum ich keine Binder language verwende:
Ich habe ein Service Programm DasWirdNix in Produktion, das bereits n Exporte hat.
Im Rahmen eines Hotfixes 1 kommt ein Export hinzu.
Im Rahmen eines anderen Hotfixes entsteht eine Variante, die ebenfalls einen Export mehr hat.
Das ist jetzt nicht mehr elementar konsolidierbar - mache ich keinen Rebind knallts im buchstäblichen Sinne irgendwo - und das bei jeder folgenden Änderung!!!
Noch ein paar Marginalien:
Ohne Binder Language werden die Exporte alphabetisch sortiert (impliziert auch CCSID des Jobs!!!), da wird also nicht "hinten" angehängt, da wird einsortiert, unabhängig davon, wo ich den Export physikalisch in der Quelle platziere!!!
Aktivierungszeiten werden dominiert von der Speicher Allokation und dem eventuellen öffnen von Dateein und solchem - alles andere kann man vernachlässigen. Auch den Unterschied zwischen statischem und dynamischem Aufruf kann man getrost vernachlässigen. Am einfachsten macht man hier was falsch mit Riesen Service Programmen (deshalb hat man ja auch des verzögerte binden eingeführt).
Wenn das mit einem einfachen Command ohne Binder Language geht und man nix falsch machen kann, dann gehört das ins Betriebssystem und dann ist mir das auch Wurscht...
Similar Threads
-
By Dick Dekker in forum NEWSboard Server Software
Antworten: 0
Letzter Beitrag: 14-01-03, 14:14
-
By Kirsten Steer in forum Archiv NEWSblibs
Antworten: 0
Letzter Beitrag: 04-07-02, 06:31
Tags for this Thread
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