Eigene Character-Funktionen

[Fuerchau]

Wie ich eingangs erwähnte hat da nun jeder seine eigene Meinung.
Diese Diskussion hatten wir schon des öfteren.
Wie heißt's doch so schön: "Jeder ist seines Gückes...".

[Fuerchau]

Noch mal zurück bezgl. CONST:
Ihr habt recht, was die Adresse angeht:
Bei CONST wird ggf. keine Kopie erstellt sondern tatsächlich bei Reference.
Solange die aufgerufene Prozedur dies mittels CONST auch so definiert ist eine Änderung nicht möglich.
Der Compiler weist Zuweisungen (auch bei Strukturen) sowie %ADDR() auf ein CONST ab.
Definert man die Prozedur extern dann ohne CONST ist ein Ändern der Struktur tatsächlich möglich.
Für die Aufruffunktion gibt es keine Signatur, die zur Laufzeit geprüft wird, so dass hier auch der Binder (CRTPGM) scheitert.

Sicherheit bietet hier VALUE.
Bei VALUE wird der Inhalt auf den STACK gelegt, also grundsätzlich kopiert. Die aufgerufene Funktion kann den Parameter auch wirklich nur verarbeiten, wenn er auf VALUE definiert ist. Bei einer Definition als CONST oder als Referenz gibt es einen Zeigerfehler beim Zugriff.
VALUE-Werte sind zur Laufzeit änderbar ohne den Aufrufer zu stören.

Klar hat VALUE insofern den Nachteil, das hier ggf. große Werte (mangls Platz) nicht übergeben werden können.

[BenderD]

... der Hauptnachteil bei Value ist, dass SQL bei create function/procedure damit Probleme hat. RPG ist und bleibt eine Sammlung von workarounds gemäß der Bedeutung seiner Abkürzung: Raten Probieren Geht nicht

D*B

[Fuerchau]

Da SQL-Prozeduren/Funktionen generell By Reference aufgerufen werden, kann ich ja bei externen Programmen Wrapper für meine Value-Übergabe machen.
Stören tut das auch nicht nennenswert.
Das Problem ist da eher, dass man sich da meist von parallelen Fetaures verabschiedet.

[andreaspr@aon.at]

RPG ist und bleibt eine Sammlung von workarounds gemäß der Bedeutung seiner Abkürzung: Raten Probieren Geht nicht

Und was sagst du bei Java?
Ich hätte Raten und Probieren eher dort erwartet.
z.B.
*) je nachdem mit welcher Java Version das Programm aufgerufen wird, wird beim Signieren wird der Hash-Wert unterschiedlich ausgegeben.
*) Verwendetes Jar-File A benötigt Jar-File B dieses ist jedoch nicht mit Jar-File C kompatible und kann nur unter einer Bestimmten Java Version aufgerufen werden.

Da finde ich RPG (auch wenn es leider in vieler Hinsicht rückständig ist) sehr angenehm, da ich dort eigentlich so gut wie nie solch komische Phänomene hatte.

[BenderD]

Und was sagst du bei Java?
Ich hätte Raten und Probieren eher dort erwartet.
z.B.
*) je nachdem mit welcher Java Version das Programm aufgerufen wird, wird beim Signieren wird der Hash-Wert unterschiedlich ausgegeben.
*) Verwendetes Jar-File A benötigt Jar-File B dieses ist jedoch nicht mit Jar-File C kompatible und kann nur unter einer Bestimmten Java Version aufgerufen werden.

Da finde ich RPG (auch wenn es leider in vieler Hinsicht rückständig ist) sehr angenehm, da ich dort eigentlich so gut wie nie solch komische Phänomene hatte.

... wenn mans (s = Java) kann, braucht man weder raten noch probieren. Ich gebe dir einen Rabatt, wenn ich wieder mal einen Kurs halte...

D*B

[Fuerchau]

Dem Phänomen begegnet man auch leider im Internet.
Da gibt es jetzt aktuell Java 1.7, bei bestimmten Internetseiten wird aber die Javaversion wohl abgeprüft und noch 1.6 verlangt. Soviel zur Kompatibilität.
Was die Signaturen angeht, so ist man ähnlich wie eben bei Java oder .NET eigentlich gezwungen, auch den Programmen, wenn sich die Signatur ändert, dann auch neue Namen zu vergeben.
Dann gibts die Verdrückung eben nicht.
Anpassen des BNDDIR auf die neuen Programme und Signaturen, dann nimmt der Binder beim nächsten verlinken eben die neue Version.
.NET macht das eigentlich noch intensiver. Hier wird man gewungen eine version zu hinterlegen und beim Importieren gezielt diese Version zu benennen.
Bei Java importiert man eine Lib. Hat die neue version dann leider den selben Namen wie die alte, gibts halt das Problem.
Dies wird dann sauber mittels Interfaces an Stelle von Direktaufrufen geregelt.
Dies könnte man ebenso in RPGLE realisieren, in dem man grundsätzlich Wrapperfunktionen zur Verfügung stellt (eben Interfaces), die dann für den Aufruf der jeweils aktuellen Originalversion zuständig sind. Diese könnten sich auch per Procedurepointer (Benders Toolbox) dynamisch die Adressen besorgen.

Möglichkeiten gibt es viele, man muss sie nur nutzen.

[BenderD]

Da gibt es jetzt aktuell Java 1.7, bei bestimmten Internetseiten wird aber die Javaversion wohl abgeprüft und noch 1.6 verlangt. Soviel zur Kompatibilität.

... das macht keinerlei Sinn, was unter 1.7 gewandelt ist, läuft auch unter 1.6 - immer und überall!

.
Was die Signaturen angeht, so ist man ähnlich wie eben bei Java ... eigentlich gezwungen, auch den Programmen, wenn sich die Signatur ändert, dann auch neue Namen zu vergeben.

Java arbeitet mit Function Overloading und löst zur Laufzeit nach Name und Schnittstellendefinition auf. Da muss nix umbenannt werden.

Bei Java importiert man eine Lib. Hat die neue version dann leider den selben Namen wie die alte, gibts halt das Problem.

Wer sich nur an die minimalsten Konventionen (Best practices) hält, der nimmt seine umgekehrte URL in seine package Hierarchie auf, dann bekommt man einen weltweit eindeutigen Namensraum - deswegen fangen alle packages meiner Anwendungen und Komponenten mit de.bender_dv an. Da gibt es nie und nimmer Probleme.

Dies könnte man ebenso in RPGLE realisieren, in dem man grundsätzlich Wrapperfunktionen zur Verfügung stellt (eben Interfaces), die dann für den Aufruf der jeweils aktuellen Originalversion zuständig sind. Diese könnten sich auch per Procedurepointer (Benders Toolbox) dynamisch die Adressen besorgen.

Möglichkeiten gibt es viele, man muss sie nur nutzen.

Der wesentliche Unterschied hierbei ist, dass der Compiler hier absolut nichts für einen tut, was bei Java selbst bei upcasts noch besser aussieht.

Anpassen des BNDDIR auf die neuen Programme und Signaturen, dann nimmt der Binder beim nächsten verlinken eben die neue Version.

Bei RPG wird aus mehreren ungeprüften Quellen (Quelldatei des Objektes, Copy Strecken, Binding Directory, Binder Source) zur Erstellungszeit ein lauffähiges Objekt zusammengewürfelt und dann werden zur Laufzeit Importe nach Hausnummer blind gezogen - ich empfehle hier ganz eindeutig Risiko Minimierung! Am Rande sei nur vermerkt, dass ich bisher in jeder Umgebung, in der ich bisher gearbeitet habe, Doubletten von Binding Directories, Binder Quellen, Copy Strecken gefunden habe und nur in den seltensten Fällen Change Management Tools eingesetzt wurden, selbst bei Software Häusern.

D*B

[andreaspr@aon.at]

... wenn mans (s = Java) kann, braucht man weder raten noch probieren. Ich gebe dir einen Rabatt, wenn ich wieder mal einen Kurs halte...

Meine Frage war aber nur rein interessenshalber und weniger als Angriff gemeint
Das gleiche kann man auch über RPG sagen. Und da gibt's auch gerne Schulungen

[BenderD]

Lieber Andreas,

ich habe Dein Statement eher als Antwort, denn als Frage aufgefasst - in diesem Sinne entschuldige ich mich für die harsche Replik.

Es gibt einen ganz fundamentalen Unterschied zwischen RPG (erst recht CL, COBOL vielleicht etwas weniger) und Java. Java ist extrem auf Defensivität ausgerichtet (das ist auch eine Gnade der späten Geburt):
- Der Compiler ist extrem pingelig und prüft alles ab, was auch nur im entferntesten prüfbar ist!
- das binden von Komponenten erfolgt zur Laufzeit und auch hierbei wird erneut geprüft
- man muss sich hier schon Mühe geben einen Laufzeitfehler hinzubekommen ohne durch 0 zu dividieren.
Dazu kommt noch, dass selbst kostenfreie Tools Funktionalität mitbringen, die man bei RPG nicht einmal für Geld bekommt. Mit diesen Werkzeugen kommt überhaupt niemand auf die Idee eine einzelne Class (entspricht Programm) für sich selber zu wandeln und in Produktion zu werfen und dann die Luft anzuhalten obs knallt oder funzt. Und seien wir RPG Programmierer doch mal ehrlich: Überraschungen der dritten Art, dass ein Programm beim ersten Einsatz in Produktion Amok fährt, sind uns doch nicht fremd - und das muss ich für meinen Blutdruck nicht mehr alltäglich haben.

D*B

[B.Hauser]

Meine Frage war aber nur rein interessenshalber und weniger als Angriff gemeint
Das gleiche kann man auch über RPG sagen. Und da gibt's auch gerne Schulungen

+1

In einer sauberen RPG/ILE Umgebung in der es genau 3 Regeln gibt:
1. Eine Quelle ergibt entweder genau ein Programm oder genau ein Service Programm
2. Neue exportierte Prozeduren werden immer ans Ende der Quelle hinzugefügt.
3. Umwandlung erfolgt über einen speziellen Befehl (der mit entsprechenden Einstellungen im PDM oder RDi) hinterlegt ist

kann jeder noch so unbedarfte ILE Programmierer problemlos modular programmieren.
Viel problematischer ist es zu wissen, was modular tatsächlich bedeutet!
Programme/Prozeduren mit ein paar hundert Statements sind mit Sicherheit NICHT modular.

Wenn man dan außerdem die Quellen für Programme und Service-Programme in unterschiedliche Quellen-Dateien aufteilt und erklärt, die Quellen in QSRVPGMSRC werden mit CS (Compile Service-Programm) und die in QPGMLESRC mit CP (Compile Service-Programm) umgewandelt, ist es selbst für den klassischen OPM Programmierer möglich Quellen zu ändern und die entsprechenden Objekte problemlos neu zu erstellen.
In einigen Firmen, in denen mein Compile-Befehl verwendet wird, wissen die Programmierer noch nicht einmal, dass sie mit Bindersprache und Binderverzeichnissen arbeiten!

Birgitta

[Fuerchau]

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.