rpg2cpp - Opensource Entwickler gesucht

[NEich]

Einerseits tolles Projekt, da mal jemand über seinen Tellerrand schaut und gut für sein Projekt recherchiert, andererseits, was/wem soll das Projekt denn (was) bringen?

RPG Anwendungen laufen meist auf der iSeries, weil sie dort den nötigen stabilen Untergrund haben, und einen nativen überaus performanten Datenbankzugang den man mit SQL (ich gehe mal davon aus du hast dir dazu noch nicht viele Gedanken gemacht) einfach nicht toppen kann (ich stelle diese Behauptung einfach mal in den Raum).

Zumal bezweifle ich, dass du, oder wer auch immer sich ebenfalls mit RPG Compilern beschäftigt, nicht mit der IBM Schritt halten kannst was die Weiterentwicklung von RPG angeht.

Einen Einsatz im produktiven Umfeld kann ich mir daher nicht vorstellen, wer also sollte dann das fertige Produkt (falls es fertig wird) benutzen?

[emax]

Einerseits tolles Projekt, da mal jemand über seinen Tellerrand schaut und gut für sein Projekt recherchiert

Danke.

andererseits, was/wem soll das Projekt denn (was) bringen?

Mir.

performanten Datenbankzugang den man mit SQL (ich gehe mal davon aus du hast dir dazu noch nicht viele Gedanken gemacht) einfach nicht toppen kann (ich stelle diese Behauptung einfach mal in den Raum).

Ich weiss nicht, ob man das toppen kann. Wenn man mal Leistung/Euro rechnet, könnte die Rechnung schon ganz anders aussehen. Und die Frage wäre ja sicher auch, was man mit so einen Compiler überhaupt machen will: sicher keine Massendaten verarbeiten, z.b. die Rechnungen der Telekom drucken, oder die Bankauszüge der Bank of Tokyo.

Zumal bezweifle ich, dass du, oder wer auch immer sich ebenfalls mit RPG Compilern beschäftigt, nicht mit der IBM Schritt halten kannst was die Weiterentwicklung von RPG angeht.

Och joh. Klaro, in meinem Wohnzimmer, an Samstag-Abenden, mach ich als one-Man-Show die ganze IBM platt....

Also mal im Ernst. Ist natürlich Blödsinn, die komplette IBM-Entwicklung einfach mal so nachbilden zu wollen. Ich denke, besonders in Hinblick auf die Umgebung OS/400 käme der Versuch wohl schlicht einer Gotteslästerung gleich. Es wird sicher RPG-III - kompatibel sein können, und hoffentlich auch RPG/400. Dann aber eben ein bestimmtes Release, und gut wärs. Das hindert natürlich nicht daran, auch neue Features dazuzupacken.

Andererseits könnten Möglichlkeiten geschaffen werden, die IBM nicht bietet:

- natives Web-Interface, z.B.
- native Oracle-Anbindung (oder gibts die schon?)
- beliebig grosse Alpha-Felder (bis 4GB)
- beliebig grosse numerische Felder und Genauigkeit
- native grafische Benutzeroberfläche (Qt/X11/gtk ...)

Die Frage ist also: macht rpg2cpp der IBM alles nach? Macht es manche Dinge vielleicht besser? Oder gibt es einen gemeinsamen Nenner (Release xyz), und darüberhinaus ein paar goodies für Linux/Windows?

Spannende Fragen, die sich vielleicht in ein/zwei Jahen stellen könnten.

Einen Einsatz im produktiven Umfeld kann ich mir daher nicht vorstellen, wer also sollte dann das fertige Produkt (falls es fertig wird) benutzen?

Da ich selber aus der AS/400-Ecke stamme, weiss ich wohl, das die Opensource-Idee es dort eher schwer hat, und die Motivationen für solche Aktivitäten (nicht bei allen, aber überwiegend) kaum bekannt sind.

Opensource Entwicklungen enstehen nicht aus ökonomischen Erwägungen, sondern aus Spass an der Sache, und schlicht deshalb, weil die jeweilige Sache häufig eine Herausforderung ist. Unter diesem Aspekt entzieht sich das Ganze daher praktischerweise jeder ökonomischen Betrachtung. Ich hab's oben schon geagt: im Moment nützt es _mir_. Weils Spass macht.

Ob das irgendwann fertig wird, weiss ich nicht, aber es ist Hobby: die einen programmieren, weil sie Geld verdienen müssen, die anderen verdienen Geld, weil Ihnen das Programmieren so viel Spass macht. Ich zähle mich zur letzteren Kategorie. Alle paar Tage ein neues Feature einzubauen, und dann festzustellen, dass es sich exakt so verhält, wie das Original - das ist regelrecht spannend.

Ob es irgendwann prduktiv eingesetzt wird, weiss ich natürlich nicht, und offengestanden habe ich auch gar keinen Grund, darüber nachzudenken. Aber es hat sich schon oft gezeigt, dass eine Sache, wenn sie erst mal an Profil und Funktion gewinnt, zum Selbstläufer wird.

Im speziellen Fall RPG allerdings wäre das überraschend. Denn in der Regel werden diejenigen, die C++/Java et.al. beherrschen kein Interesse an einen RPG-Compiler haben: sie haben ja (vermeintlich) Besseres.

Ich selber trauere dagegen den Fähigkeiten von RPG nach. Ich muss hier sicher nicht erklären, wie schnell damit Programme zu schreiben sind, wie unproblematisch Datendefinitionen und Satzverarbeitung sind, ebenso wie die Masken-Handhabung, die präzise Arithmetik, etc...

Hätte ich heute einen RPG-Compiler unter Linux, längst hätte ich mir eine eigenen Rechnungsschreibung gebaut (ich bin selbständig), und meine Kunden- und sonstigen Daten einer RPG-Entwicklung anvertraut.

Eines ist klar: es soll kein OS/400 nachgebaut werden, dafür haben wir ja unsere AS/400. Auch CL ist kein Thema. Es geht um RPG, und selbst da muss ich sagen, dass RPG/400 zunächst "angestrebt" ist, und es sieht eigentlich ganz danach aus, dass das auch klappen könnte. Sogar extern beschriebene Dateien erlaubt das Design.

Aber ob das so klappt, ob es produktiv wird, ob die Welt es braucht: das sind Kategorien, über die ich mir eigentlich keine Gedanken mache: es ist Hobby.

beste Grüsse
emax


PS: da ich keine AS/400 zum Testen habe, werde ich hier sicher noch öfter um Hilfe bitten, hier gleich die erste Frage:

Programm A macht eine CALL auf Programm B, welche Programm C CALLt. Soweit ok.

Wenn nun Programm C wieder Programm A aufruft, wird dann eine neue Kopie geladen (mit allen Initialisierungen, Bezugszahlen auf Null etc), oder wird die Instanz aufgerufen, die am Anfang stand (und damit auch die Variableninhalte, Satzzeiger und Bezugsahlen übernommen) ?

Müsste ich für mein CALL-Interface wissen.

Freu mich auf Antwort.

[Frank Hildebrandt]

Da gibt es der Möglichkeiten einige.

Programm A ruft Programm B auf. Programm B wird mit *INLR = *On verlassen. Dann befindet sich Programm B nicht mehr im Aufrufstapel und auch der Speicher mit den Variablen ist weg.

Programm A ruft Programm B auf. Programm B wird mit *INLR = *Off und "Return" verlassen. Dann befindet sich Programm B nicht mehr im Aufrufstapel, jedoch ist der Speicher mit den Variablen noch vorhanden. Jetzt ruft Programm A noch einmal Programm B auf. Dann haben die Variablen die gleichen Werte, die sie hatten, als das Programm B mit *INLR = *Off und "Return" verlassen wurde.

Programm A ruft Programm B auf. Programm B ruft Programm A auf. In RPG II und RPG III werden rekursive Aufrufe grundsätzlich mit einem Fehler belohnt. In RPG IV gibt es nur dann einen Abbruch, wenn sich die Programme, die sich rekursiv aufrufen in der gleichen Aktivierungsgruppe befinden. Bei unterschiedlichen Aktivierungsgruppen funktionieren auch rekursive Aufrufe. Jedes Programm hat dann seinen eigenen Speicher für Variablen und beim Aufruf des Programms wird dieser initialisiert und nicht vom vorhergehenden Aufrufstapeleintrag des gleichen Programms übernommen.

[emax]

Klare Antwort, herzlichen Dank.

Die LR/RT - Eigenheiten waren mir klar, nur der letzte Fall, wenn "A" zwei mal, aber von unterschiedlichen Programmen aufgerufen wird, das war mir unklar.

Das heisst also, dass je unterschiedliche Programme (i.e. CALLER) immer eigene Instanzen der aufgerufenen Programme bekommen.

Bis denne und danke!
emax

[Fuerchau]

Bevor man sich für kommerzielle Projekte einen OpenSource-Compiler zulegt mit allen Nachteilen (Wartung, Funktionalität, o.ä.) 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.

Für die Spielwiese mag so ein Projekt ganz nett sein, aber ernsthaft wird es wohl kaum einen Erfolg bringen.
Probleme hast du ja bereits bei den Felddefinitionen festgestellt:
- Alle Felder sind grundsätzlich Single-Felder ausser bei Strukturen mit qualified.
- Überlagerung von Definitionen (E-Definition mit I-Definition bei Namensgleichheit, DIM/OCCURS, Overlay, u.v.m.)

[emax]

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:

 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

[Fuerchau]

Deine Aussagen sind ja auch alle korrekt, das habe ich nicht bezweifelt
Ich bezog mich lediglich auf das RPG-Projekt.

Ansonsten:
Was der RPG-Compiler macht, lässt sich ziehmlich klar an der MI-Liste abelesen (insbesonders die Definitionen) und ich nehme mal an, dass du deine Infos auch daraus gezogen hast (ich nähmlich auch).
Leider gibt es diese MI-Liste bei ILERPG nicht mehr.

Und was neue Projekte angeht:
Sicherlich werden neue Anwendungen nun alle in C/C++/Java/VB/.NET/PHP/HTML/DHTML/XML/ASP o.ä. entwickelt, aber auf der AS/400 sehe ich nur RPG, ILERPG und VisualRPG, eher selten noch COBOL.
Manche versuchen sich auch in Web-Applikationen mit AS/400.

Was meine Erfahrungen angeht, so hat sich herausgestellt, dass, neben allem Komfort für den Bediener mit einer grafischen Oberfläche, der sog. Transaktionsdurchsatz mit 5250-Greenscreen einfach unschlagbar ist.

Unter Jobgesichtspunkten bringt das natürlich Arbeitsplätze, hierzu allerdings ein Beispiel:
Nach der Einführung der grafischen Oberfläche für eine Buchhaltung wurde die gesamte Arbeit von 2 Halbtagskräften nicht mehr bewältigt. Da man sich nun scheute, zusätzliche Kräfte einzustellen bzw. aus Halbtags- Vollzeitkräfte zu machen (die sich im übrigen weigerten) hat man kurzerhand die grafische Oberfläche gestrichen und wieder auf 5250-Greenscreen umgestellt.

Begründung:
Viele grafische Dialoge lassen sich nicht ausschließlich mit der Tastatur bedienen sondern bestehen aus einer Mischung aus Maus und Tastatur-Eingaben. Dies führt zu einem ständigen Wechsel der Handbewegungen, Fehlklicks o.ä.
Sicherlich kann man den Durchsatz mit viel Übung steigern, aber solange die Maus im Spiel ist, kann nie diese Transaktionsrate erreicht werden.

Ich entwickle auch selber Windows- und Clientprogramme, der größte Teil meiner Arbeit ist und bleibt (meine persönliche Überzeugung) RPG-Entwicklung auf der AS/400 egal ob mit/ohne ILE oder mit/ohne SQL.

Dies soll kein persönlicher Angriff sein

[emax]

Was der RPG-Compiler macht, lässt sich ziehmlich klar an der MI-Liste abelesen (insbesonders die Definitionen) und ich nehme mal an, dass du deine Infos auch daraus gezogen hast (ich nähmlich auch).

Nein, leider nicht. Da ich z.Zt. leider keine AS/400 zur Verfügung habe, musste ich mein Design einzig durch überlegen erarbeiten.

Es gibt hinsichtlich Datenmanagement schlicht keine andere Möglichkeit. Im Prinzip lässt sich sagen, dass alle Compiler am Schluss mit Wasser kochen. So kann man mit etwas Nachdenken eigentlich die Arbeitweise "re-engineeren".

Leider gibt es diese MI-Liste bei ILERPG nicht mehr.

Übel. An so einer Liste hätte ich echt Interesse. Im Moment brauche ich sie noch nicht, aber ich werde gelegentlich mal darauf zurückkommen.

dass, neben allem Komfort für den Bediener mit einer grafischen Oberfläche, der sog. Transaktionsdurchsatz mit 5250-Greenscreen einfach unschlagbar ist.

Absolut d'accord!

Ich habe mich schon oft über die Dösköppe geärgert, die da meinen, die "nicht-grafischen" Masken der 5250-Welt seien "veraltet". Blödsinn: sie sind die Reduktion auf das Wesentliche.

Ich arbeite beispielsweise ausschliesslich mit dem Editor "emacs" (daher mein Nick). Und Warum? Weil ich damit den ganzen Tag keine Maus anfassen muss: tierisch schnell, und keine Schulterschmerzen wegen feinmotorischer Dauerbelastung.

Ich erinnere mich gut, wir hatten für die Firma "MAC-Jeans" eine Auftragserfassung geschrieben. Die Ladies dort hatten uns ganz genau gesagt, was sie brauchten, und jede Überflüssige Eingabe abgelehnt. Das muss man gesehen haben: Die Erfassung eines Auftrages geschah völlig ohne hinzugucken: das Auftragsblatt lag links neben der Tastatur, da haben die nur draufgeguckt, und blind die Daten reingehämmert. Ruck zuck, war so ein Auftragskopf in vielleicht 5-10 Sekunden drin.

Wenn wir denen mit Mausbedienung gekommen: wir wären den Kunden losgewesen.

Nach der Einführung der grafischen Oberfläche für eine Buchhaltung wurde die gesamte Arbeit von 2 Halbtagskräften nicht mehr bewältigt. Da man sich nun scheute, zusätzliche Kräfte einzustellen bzw. aus Halbtags- Vollzeitkräfte zu machen (die sich im übrigen weigerten) hat man kurzerhand die grafische Oberfläche gestrichen und wieder auf 5250-Greenscreen umgestellt.

Meine Rede. Wenns nur die "young professionals" begreifen würden. Aber die kommen von der Uni und haben schlicht keinen Dunst, wie "Datenverarbeitung" draussen beim Kunden in der Praxis wirklich läuft.

Es ist eine Schande, dass Geräte wie die AS/400, wasserdicht wie kein anderes System, heutzutage Windows-Rechnern weichen müssen.

Viele grafische Dialoge lassen sich nicht ausschließlich mit der Tastatur bedienen sondern bestehen aus einer Mischung aus Maus und Tastatur-Eingaben. Dies führt zu einem ständigen Wechsel der Handbewegungen, Fehlklicks o.ä. Sicherlich kann man den Durchsatz mit viel Übung steigern, aber solange die Maus im Spiel ist, kann nie diese Transaktionsrate erreicht werden.

Verkrampfungen, Sehnenscheidentzündungen und Schulterschmerzen eingeschossen.

Ich entwickle auch selber Windows- und Clientprogramme, der größte Teil meiner Arbeit ist und bleibt (meine persönliche Überzeugung) RPG-Entwicklung auf der AS/400 egal ob mit/ohne ILE oder mit/ohne SQL.

Wohl dem, der das auch in Zukunft noch tun kann.

Dies soll kein persönlicher Angriff sein

Ach Quark, so hab ich's auch nicht aufgefasst.

Gruss
emax

[emax]

Die DSPLY und CALL operationen sind nun implementiert.

DSPLY unterstützt *M - Nachrichten aus QUSERMSG.

QUSERMSG wird in der *LIBL gesucht, die ihrerseits wieder aus dem QUSERPRF gelesen wird.

CALL unterscheided *INRT und *INLR: je nach Beendigung behält das gerufene Programm seinen letzten Status (nebst Variablen, Indicators etc) , oder wird neu geladen (inklusive initialisierung usw.).

MOVEL auf alpha-Felder wird nun weitgehend unterstützt. Numerische Werte für MOVEL kommen später dran.

Gruss
Emax

[emax]

Wie sind denn auf der AS/400 die Libraries organisiert?

Was ist die Toplevel-Library? Wo liegen die anderen Libs?

z.B:

    QSYS
 	QGPL
 	MYLIB
 	QS36F

Oder wie sieht die Organisation aus?

Wer kann mir helfen?

Besten Dank
emax

[Fuerchau]

QSYS ist die Haupt-Lib, alle Lib's (ausser QSYS) sind als Objekte in der Lib.

Objekte identifizieren sich immer über Objektname und Art, so dass durchaus gleiche Objektnamen vorhanden sein können.
Am besten bildet sich die Struktur im IFS /QSYS.LIB wieder.

Achtung:
QTEMP ist keine physische Lib sondern eine Speicherlib, die alle Objektarten aufnehmen kann, jedoch bei Jobende gekillt wird.
Entspricht ggf. einem Task-spezifischen TEMP-Verzeichnis.

[emax]

Danke für die schnelle Antwort.

Könntest Du ein Listing posten, in dem möglichst viele unterschiedliche Objekt-Arten sind?

.LIB weiss ich jetzt ja, aber es gibt ja noch andere.

Würde ich dann bei Bedarf genauso übernehmen.

Beste Grüsse
emax