-
 Zitat von dschroeder
Ein Sourcemember beinhaltet immer den Code für ein Modul. In einem Modul können mehrere exportierte Procedures sein. Mehrere Module können zu einem Serviceprogramm zusammengebunden werden.
Habe ich das richtig verstanden? (Da bei uns ein Sourcemember (fast) immer zu nur einem Serviceprogramm führt, haben wir mit Modulen zur Zeit nichts am Hut.)
Procedure := aufrufbare Einheit, hat lokale Variablen und kann auf globale Variablen des Moduls zugreifen.
exportierte Procedure := kann aus anderen Modulen benutzt werden.
exportierte Variable := Pfui, Bäh!
Module := Compileeinheit, wird aus Quelle erstellt. Kann in PGM oder SRVPGM per copy eingefügt werden.
SRVPGM := macht Module verfügbar (bind by reference).
Binder Source := legt fest, was von ausserhalb des SRVPGMs sichtbar ist (Parameter beim CRTSRVPGM: *all oder Binder Source) und gibt die Möglichkeit die Reihenfolge der Exporte selber festzulegen und selber eine Signatur festzulegen.
 Zitat von dschroeder
Es würde ... doch so sein, dass die Datenstrukturen versioniert werden, oder? Also zunächst heißt die Struktur "KUNDE_Datensatz", nach einer Felderweiterung dann "KUNDE_DatensatzV2"
Kann man so machen, wenn einem nix besseres einfällt (man könnte ja auch seine Dateien nach Erstellungsdatum durchnummerieren), in vielen Fällen des täglichen Lebens, könnten einem auch sprechendere Namen einfallen. Entscheidend ist, dass die vorherigen "Varianten" ihre Namen behalten. Dann ändert sich an allem bisherigen nix. Meist ist es so, dass bisherige Programme ein zusätzliches Feld auch nicht brauchen, dann packt man die auch nicht an (warum soll man diese Programme verkomplizieren). Da wo das gebraucht wird, wird eine View benötigt, die das "neue" Feld benötigt (aber vielleicht andere nicht), dafür gibt es dann eine zusätzliche View.
=> mehr Views und die Programme werden einfacher, die Zugriffe schneller! (Wird so ein Feld überall gebraucht,kann man nicht benötigte Views löschen - es ist aber keineswegs Ziel in Programme Felder reinzunehmen, nur weil sie "da" sind!).
Am Rande sei erwähnt: Es gibt nur 2 Varianten bei SQL Zugriffen, die gegen Seiteneffekte stabil sind.
select * und e DS oder select Feldliste in Feldliste, alles andere ist no risc, no fun!
 Zitat von dschroeder
Bei Parameteränderungen gebe ich dir Recht. Wenn man breaking changes macht, sollte man eine neue Version erzeugen. Solange wir mit zusätzlichen optionalen Parametern hinkommen, ist das aber nicht unbedingt nötig, finde ich.
Wenn sich alle dranhalten, kann man das so machen. Wenn nicht: no risc, no fun! (Ich bin für fun ohne risc!)
mfG
D*B
Similar Threads
-
By ML-Software in forum NEWSboard Server Software
Antworten: 0
Letzter Beitrag: 22-11-21, 13:43
-
By NEWSolutions Redaktion in forum NEWSolutions artikel
Antworten: 0
Letzter Beitrag: 05-10-16, 04:49
-
By NEWSolutions Redaktion in forum NEWSolutions artikel
Antworten: 0
Letzter Beitrag: 10-02-16, 17:43
-
By ibiuser in forum Archiv NEWSblibs
Antworten: 0
Letzter Beitrag: 10-02-11, 18:43
-
By ibiuser in forum Archiv NEWSblibs
Antworten: 0
Letzter Beitrag: 10-02-11, 18:41
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