Eigene Character-Funktionen

[Kurmas Zeschlon]

Hallo zusammen,

nachdem ich zuletzt hier und da Probleme mit zu wenig dynamischem Speicher hatte -- ein Konzept, dass ich noch nicht richtig verstehe -- möchte ich hier mal fragen, wie ich am intelligentesten Funktionen/Prozeduren designe, die ähnlich wie die BIFs %Xlate, %ScanRpl etc. Charactervariablen manipulieren.

Bisher habe ich hierzu VARYING-Felder mit LEN(4000000) genutzt. Parameter jeweils mit CONST versehen.

Also:

     
     P fURLEscape      B                    EXPORT
     D fURLEscape      PI              A    LEN(4000000) VARYING
     D  Text                           A    LEN(4000000) CONST VARYING

Ist es ratsam, so vorzugehen? Durch den Rückgabewert brauche ich ja mehr Speicher, als wenn ich nur einen per Referenz übergebenen Parameter hätte, oder? Es scheint Probleme zu geben, wenn ich viele solcher Funktionen in einem Programm benutze.

Wie machen das denn die BIFs? Denen kann man sehr große Felder übergeben und bekommt auch schöne Rückgabewerte. ohne dass ich bisher auch bei großen Feldern Probleme bekommen hätte. Kann man deren Verhalten simulieren?

Schöne Grüße

[andreaspr@aon.at]

Hallo,
Für genau diese Situation gibt es in RPG ab 7.1 das Schlüsselwort RTNPARM bei der Procedurdefinition:

D getFileData     pr    a     varying len(1000000)
D                             rtnparm
D file                  a     const varying len(500)

/free
  data = getFileData ('/home/mydir/myfile.txt');

[B.Hauser]

... aber Vorsicht!
Der Aufruf mit Rückgabe-Wert funktioniert nur beim Aufruf aus RPG.
Beim Aufruf aus anderen Programmiersprachen muss der Rückgabe-Wert über den ersten Parameter abgehandelt werden.

Birgitta

[Fuerchau]

Das Problem mit dem Speicher beginnt ja schon beim Übergabeparameter.
Wenn dieser CONST ist, legt der Compiler ja automatisch eine Kopie in der Größe an.
Aber ohne CONST kann ich keine dynamische Übergabe kodieren:
MyFunc(Var1);
MyFunc('Text');
Problematisch wirds dann noch bei Rekursion und geschachtelten Funktionen.
Bifs sind intern wohl etwas anders kodiert.

Dynamisch geht es eigentlich nur per Pointer.
Allerdings muss die Aufrufkonvention genau eingehalten werden.

Beschränke dich doch einfach auf max. 32K-Variablen, das reicht in 99,999% aller Fälle.

[B.Hauser]

Bei VALUE wir immer eine Kopie erstellt.
Bei CONST nur dann, wenn die Parameter-Definition (Aufruf/Prototyp) abweichend ist. Es wird immer ein Pointer (entweder auf das Original-Feld oder die Kopie übergeben.

Birgitta

[Fuerchau]

CONST erzwingt ebenso eine Kopie, damit die aufgerufene Funktion den Speicher nicht ändern kann.
Dies ist Sinn und Zweck von CONST.
VALUE arbeitet (fast) genauso, nur dass scalare Datentypen nicht kopiert werden sondern direkt im Stack abgelegt werden (CLLE-Problem).
Bei Zeichenvariablen wird der Inhalt kopiert und ein Pointer im Stack abgelegt.
Die Kopie benötigt dann halt den Platz.

[BenderD]

     
     P fURLEscape      B                    EXPORT
     D fURLEscape      PI              A    LEN(4000000) VARYING
     D  Text                           A    LEN(4000000) CONST VARYING

Es scheint Probleme zu geben, wenn ich viele solcher Funktionen in einem Programm benutze.

... was für Probleme? alles was lokal definiert ist, ist automatic storage, wird also zur Laufzeit für die Lebensdauer der Procedure allociert und wieder freigegeben. Addieren tut sich das allenfalls, wenn das geschachtelt ist. Die %bifs werden zur Compiletime aufgelöst, da kann man an der Länge noch fummeln, das geht mit eigenen Funktionen, die erst zur Bindezeit aufgelöst werden wohl nicht. Ein wenig simulieren könnte man das mit call by reference und Pointer Rückgabe, halte ich aber von der Lesbarkeit und Robustheit für Contraproduktiv.

D*B

@Baldur: das mit dem CONST scheint mir nicht so! CONST ist eigentlich nur hopefully CONST und wird zur Laufzeit nicht (in Worten: nicht!) sichergestellt.

[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