Anmelden

View Full Version : Eigene Character-Funktionen



Seiten : 1 2 [3]

andreaspr@aon.at
12-02-14, 07:50
... 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
12-02-14, 08:06
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
12-02-14, 08:21
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
12-02-14, 08:40
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.

BenderD
12-02-14, 08:55
... 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...

Rainer Ross
17-08-14, 21:23
wie wärs mal mit Pointern?

Ich denke, das Problem das du ansprichst, hat damit zu tun, dass die Summe der Variablen in einem RPG-Programm, einschließlich der Variablen in Prozeduren, 16MB nicht übersteigen darf.

Mittlerweile bietet das Teraspace-Konzept die Möglichkeit, über Pointer in einem Programm Speicher in Terabyte-Größen zu addressieren.

Auch die IBM API's nutzen Pointer zur Kommunikation z.B. das API iconv, mit dem man einen String von einer CCSID in eine andere konvertieren kann oder das API cvthc (convert character to hex).

Anbei zwei Programme, die mit Pointern kommunizieren. Performanceprobleme, wie bei der Übergabe von großen Variablen treten hier nicht auf. Das aufgerufe Programm ist bereits mit dem neuen allfree RPG geschrieben, das rufende ist noch old fashioned.

Das aufgerufene Programm entfernt einen ungültigen Hexcode aus einem String, der maximal 16MB groß ist.

Wichtig: Im Header muss alloc(*teraspace) angegeben werden, dann werden statt 8, 16 Byte große Pointer benutzt.

kleiner Tipp: große Variablen nicht mit *blanks initialisieren, sondern mit clear, das spart Performance.

Herzliche Grüße
Rainer Ross
www.myhofi.com (http://www.myhofi.com)
schnelle und komfortable Hotelsuchmaschine mit Volltextsuche – powered by IBM i

Fuerchau
18-08-14, 07:31
Dann hast du Teraspace falsch verstanden.
Default ist jeder Pointer 16-Byte, nämlich als Pointer definiert. Mit Teraspace reduziert sich der Pointer auf 8 Byte und dann als Zahl, da Pointer vom MI-Typ her 16-Byte sind. Dies ist auch eher der C-Fraktion geschuldet.
Die 16-MB-Grenze galt nur für eine DS. Man kann also durchaus mehr als 16 MB verarzten.
Außerdem stehen %alloc()-Funktionen zur Verfügung um dynamischen Speicher zu ergattern (bis die Platte platzt).

Pointer lösen nicht das Problem sondern verschlimmern es sogar noch, da nicht mal der Compiler mehr die Typisierung prüfen kann (die zur Laufzeit sowieso nicht existent ist).

Rainer Ross
18-08-14, 08:36
Danke für die Info,

dann lese ich das im Handbuch nochmal nach.

Herzliche Grüße
Rainer Ross
www.myhofi.com (http://www.myhofi.com)
schnelle und komfortable Hotelsuchmaschine mit Volltextsuche – powered by IBM i