Bevor man sich für kommerzielle Projekte einen OpenSource-Compiler zulegt mit allen Nachteilen (Wartung, Funktionalität, o.ä.)
Mal grundsätzlich zu den Opensource-Nachteilen (ohne das jetzt auf rpg2cpp zu beziehen): der leistungsfähigste C/C++ Compiler aller Zeiten ist der opensource-Compiler GNU-C, GNU-C++.

Ich arbeite zur Zeit in einem IBM-Projekt, Voice over IP. Entwickelt wird in C++.

Compiler: GNU-C++.
Plattform: IBM AIX - Systeme.

Kompiliert wird auf Kundenwunsch _auch_ in xlc (der original IBM-Compiler).

Probleme:

1. die Funktionalität: was GNU kann, kann xlc noch lange nicht.
2. die Wartung: gibt es in GNU ein Problem, ist das a) im Web meist längst bekannt, und b) üblicherweise binnen weniger Tage gefixt. Bis IBM USA in die Pötte kommt, sind wir hier längst beim nächsten Release.

Zur Sicherheit: Ikea, Sixt, die Bundesregierung u.v.a. haben ihre kritischen Systeme längst auf Opensource umgestellt. Die Polizei in NRW folgt z.Zt. mit ebenfalls über 12000 Systemen, die Stadt München ist (nach anfänglichen Bad-News durch die MS-Lobbyisten) ebenfalls dabei.

Microsoft hatte 2004 in den Staaten Webseiten gegen Linux und Opensource Software lanciert. Die Server liefen unter? Apache! - nicht unter IIS.

Zurück zu rpg2cpp: kommerzielle Projekte werden möglicherweise bald überhaupt nicht mehr in RPG gemacht. J.D.Edwards ist tot, von solchen Instanzen wie der SOBA, ASRING, der VEDA und anderen Grössen habe ich in Sachen RPG schon lange nichts mehr gehört. Und das heutzutage noch irgendwo eine DKS installiert werden würde, oder sich ein Unternehmen eine CRM-Software in RPG entwickeln lassen würde, wäre eine echte Nachricht.

Und deshalb die gute Neuigkeit: niemand braucht rpg2cpp. Das macht die Angelegenheit stressfrei.

wird man sich bei Windows-APP's wohl eher auf VisualRPG konzentrieren.
Dort ist das Windows-Handling sowie auch C-Aufufe (ILE-Definitionen) als auch SQL und Native-DB-Zugriffe enthalten.
Und unter Linux?

Für die Spielwiese mag so ein Projekt ganz nett sein
Stimmt. Es ist ein bischen wie Modelleisenbahn bauen: ein Hobby.

aber ernsthaft wird es wohl kaum einen Erfolg bringen
Kommt drauf an, was man unter Erfolg versteht: Spass an der Sache, zum Beispiel. Kommerzielle Ambitionen hat das Projekt nicht. Bis jetzt.

Probleme hast du ja bereits bei den Felddefinitionen festgestellt
Nö, ich hab sie gelöst.

Alle Felder sind grundsätzlich Single-Felder ausser bei Strukturen mit qualified.
Was immer ein "single" Feld ist: Es gibt jedes Feld im Programm nur ein einziges mal. Egal, wie oft es im Quellcode auftaucht, es hat nur ein einziges Mal eigenen Speicher: entweder selbst angelegten, oder es hat sich den von einer Datenstruktur zur Verfügung gestellten "ausgeborgt".

Wenn ein Feld (z.B. KDNR) in einer Dateidefinition (oder auch in 10 Dateidefinitionen) auftaucht, hat es trotzdem nur einmal Speicher im Programm. Wenn man ein wenig abstrahiert ist es ganz simpel:

der Feldname in einer Dateidefinition besagt lediglich, in welchen Speicher der Inhalt dieses Teils des Eingabesatzes bei einer Eingabeoperation geschrieben werden soll. Insofern stellt ein Feldname in einer Dateibeschreibung im Grunde nur einen "Named Link" zum dem Speicherbereich des Programms dar, der unter z.B. dem Namen "KDNR" erreichbar ist.

Überlagerung von Definitionen (E-Definition mit I-Definition bei Namensgleichheit, DIM/OCCURS, Overlay, u.v.m.)
s.o.: Eine E-Karte legt keine Felder oder Arrays an. Sie beschreibt lediglich die Struktur selbiger. "Angelegt" werden diese dann a) entweder implizit in einer DS mit einem "shared buffer", oder b) explizit im Programmspeicher (mit eigenem Buffer).

Gerade diese Erkenntnisse sind mit die wichtigsten im ganzen Design. aber im Grunde simpel.

Hier mal ein einfaches Beispiel zur Verdeutlichung:

Code:
 0010 IKUNDEN	 NS 01
 0020 I					   1   50KDNR
 0030 IAUFTR	  NS 02
 0040 I					   7  110KDNR
Der Compiler (auch der original Compiler) reserviert im Programm _ein mal_ einen Speicherbereich von 5 Bytes für die Kundennummer. Nun mache ich einen CHAIN auf "KUNDEN".

Die Eingabebestimmung legt KEIN Feld KDNR an, sie besagt lediglich:

"kopiere die Bytes, die im Datensatz "KUNDEN" von Stelle 1 bis 5 stehen, in den Speicherbereich, der unter dem Namen "KDNR" reserviert wurde."

Und genau das passiert bei einem erfolgreichen CHAIN auch.
Mache ich einen CHAIN auf "AUFTR", so heisst die Anweisung an das Programm:

"kopiere die Bytes, die im Datensatz "AUFTRAG" von Stelle 7 bis 11 stehen, in den Speicherbereich, der unter dem Namen "KDNR" reserviert wurde."

Genau das Gleiche gilt für E-Karten. In beiden Fällen werden Datenfelder "bsechrieben", aber nicht "angelegt".

Eine "OCCUR"-DS arbeitet im Prinzip nicht anders: Es existieren zwar n - Exemplare einer solchen Struktur. Doch ausserdem gibt es einen Basiszeiger, der auf das aktuelle Vorkommen der Struktur zeigt. Nur dieses aktuelle Vorkommen ist im Programm sichtbar.

Hole ich mit "OCCUR" ein Vorkommen der DS "nach oben", dann wird lediglich der Basiszeiger auf dieses Vorkommen gestellt, und alles läuft so weiter, als hätte die DS nur dieses eine Vorkommen.

Jetzt muss ich aber wieder an die Arbeit,

tschüss
emax