Eigene Character-Funktionen

[Kurmas Zeschlon]

Vielen Dank an Euch alle!
Zunächst einmal: RTNPARM hat geholfen.

CONST VARYING habe ich verwendet, um größtmögliche Flexibilität beim Aufruf der Funktion zu haben, also Charactervariablen verschiedener Länge und auch Literale verwenden zu können.

Bei der XML-Verarbeitung bin ich zu 4000000-Feldern übergegangen, sobald es möglich war, sodass ich Dokumente jetzt immer in einem Rutsch verarbeiten kann. Für Characterfunktionen, die allgemein eingesetzt werden sollen, sind mir also 32KB zu wenig. Vielleicht war das nicht der schlaueste Ansatz, aber inzwischen nutzen einige Programme die 4Mio-Funktionen und es wäre ein Riesenaufwand, alles wieder zurückzubiegen.

Dazu kommt ein gewisses Chaos innerhalb meiner Serviceprogramme, das aus dem Learning-by-Doing-Ansatz unserer Abteilung entspringt. Mein Konzept ändert sich, je mehr ich dazulerne. Natürlich ist das einer stringenten Architektur nicht gerade förderlich.

Könnt Ihr mir vielleicht ein Buch oder eine Schulung empfehlen, die zum Thema hat, wie man organisiert eine "Bibliothek" von Prozeduren aufbaut, diese zentral zur Verfügung stellt und wie man diese am besten wartet?

Zurzeit verfolge ich den Ansatz eines Serviceprogramms für allgemeine Funktionen und daneben weitere, die Prozeduren für verschiedene mehr oder weniger abgeschlossene Bereiche enthalten (Web-Portal, Web-Schnittstellen usw.). Vor kurzem wollte ich eine Prozedur aus einem der speziellen Serviceprogramme in das allgemeine verschieben, was zu einer Neukompilierungsorgie sondergleichen geführt hat.

Sorry, jetzt bin ich wohl ziemlich vom Thema abgekommen. Soll ich besser einen neuen Thread aufmachen?

[Fuerchau]

Auch dieses Thema wurde hier (mit unterschielichen Meinungen) schon mehrfach behandelt.
Das Neukompilieren ist nicht erforderlich, wenn man mit Bindarylanguage und eigenen Signaturen arbeitet.
Man legt
a) eine eigene Signatur fest
b) bestimmt genau die Reihenfolge der Exporte
Ohne Signatur rechnet das System an hand der Exporte immer eine eigene aus, so dass diese sich halt mit jedem neuen Export verändert, mit eigener Signatur gibts dieses Problem nicht.
Neue Export müssen immer am Ende angefügt werden!
Begründung:
Der Compiler merkt sich den Einsprungspunkt an hand der relativen Position in der Liste.
Verschiebt sich die Liste, wird ohne Signaturwechsel sogar die falsche Prozedur aufgerufen!

Ohne Bindarylanguage sortiert der Compiler (bzw. CRTSRVPGM) die Exporte alphabetisch und rechnet eine neue Signatur aus.
Dies führt dann eben zur Neucompilierungsarie damit es keine Runtimefehler gibt!

Empfehlenswert ist auch ein eigenes BNDDIR.

Wie du die Serviceprogramme organisierst bleibt letztlich dir überlassen.
Es macht aber durchaus Sinn, globale Funktionen und Business-Funktionen (nach Theman, Aufgaben)aufzuteilen.

[BenderD]

... hier fängt doch genau der Unfug an!!! Mit dieser Strategie kann ich eine Procedure genau nicht verschieben, die lässt nämlich das Entfernen eines Exports nicht zu - dann geht der Punk ab!!!

Zunächst muss man erst mal die Anforderung festlegen:
- bin ich Software Haus und brauche ein modulares Deployment
- bin ich Anwender und will schnelle Ladezeiten
- will ich maximale Modularisierung und Flexibilität

BTW: neu kompilieren ist nicht erforderlich, neues binden der verwendenden Programme/SRVPGMs reicht.

D*B

[Fuerchau]

Klar darf ich Exporte nie entfernen wenn ich neubinden/compilieren verhindern will!
Aber mal ehrlich, wer macht das schon?
Neue Schnittstellen gehören ans Ende, alte Schnittstellen sind halt per Definition "depracticated".
Anders macht es ja Java o.ä. auch.
Wenn es denn unbedingt sein muss, kann man nach dem Entfernen ja auch neubinden/compilieren.

Das Compilieren ist tatsächlich nicht erforderlich, wenn man denn die Module noch hat.
Wandelt man (häufig) direkt um, wird das Modul ja in QTEMP erstellt und ist danach (im Batch sowieso) auch weg.

Ohne Bindarylanguage und BNDDIR's würde ja das gesamte System (ILE-Runtime, C-Funktionen u.v.m.) ja gar nicht funktionieren und mit jedem Releasewechsel müsste alles neu gebunden werden.
Objekttransporte von einem zum anderen System wären unmöglich (Ende mit Kompatibilität).

Warum also Bindarylanguage nicht nutzen?
Ich habe es für mich persönlich und aus Bequemlichkeit genau so gemacht.

[BenderD]

... diesen Huddel, Exporte nach Reihenfolge, egal was das ist, macht außer ILE keiner!

Bei Java wird nix hintendran gehängt und da gibt es auch sowas wie Signatur LMAA nicht. Wenn da ein Export fehlt, dann knallt's beim Aufruf, wie sich das gehört und nicht irgendwo ganz anders mittendrin!

Das gefährliche an dem Quatsch mit der Verwendung von Binder Language und einer constanten Signatur (spechender Name dafür: LMAA) ist doch gerade, dass das völlig unberechenbar irgendwo knallt, wenn irgendein Chaot im Team da was falsch macht - und bisher habe ich in jedem Team einen Chaoten gefunden, dem sowas zuzutrauen ist. Mit einem Minimum an Change Management ist doch der rebind überhaupt kein Problem.

Das Betriebssystem kann man da nicht zum Vergleich heranziehen, da gelten doch ganz andere Qualitäts Sicherungs Kriterien - und auch da funktioniert das oft genug nicht! Da gibt es doch hier im Forum genügend Fehlermeldungen für neue Releases mit mehr als seltsamen Fehlern an Ecken wo nix geändert wurde - lass mich raten woran das auch liegt!

D*B

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