rpg2cpp - Opensource Entwickler gesucht

[kuempi von stein]

....Das Ding habe ich vor drei Monaten von meiner Platte gelöscht.........
Lass mal hören::::::

na wenn du sf.net kennst brauch ich ja nix mehr zu sagen.
gruss nach Gross-Bieberau und schönen tag noch.

k.

[emax]

da liegt das Problem: ich kenne es eben nicht so gut, als dass ich "Sachen für die AS/400" gefunden hätte.

Deshalb noch mal meine Frage: welche Sachen meinst Du denn? Würde mich echt interessieren, man lernt ja nie aus.

Also immer her demait, und Danke im Voraus!

Gruss
emax

[kuempi von stein]

da liegt das Problem: ich kenne es eben nicht so gut, als dass ich "Sachen für die AS/400" gefunden hätte.

Deshalb noch mal meine Frage: welche Sachen meinst Du denn? Würde mich echt interessieren, man lernt ja nie aus.

Also immer her demait, und Danke im Voraus!

Gruss
emax

ehm...
also ich habe einfach mal die suchfunktion da benutzt, was ja be berlios auch geht.
und wenn man bei berlios nach "AS/400" sucht findet man zwei ergebnisse...
bei sf doch schon etwas mehr. siehe hier: http://sourceforge.net/search/?words...of_search=soft
ob da irgendwas brauchbares bei ist mag ich nicht entscheiden und steht mir auch gar nicht zu.
andere suchbegriffe fördern sicherlich auch andere ergebnisse zu tage.

ich wollte da gar nicht gross drauf rumhacken auf dein projekt.
ist immer schön zu lesen, wenn leutz sich engagieren.
war mehr ne überlegung von wegen synergie und so.

bye

k.

[emax]

Das mit der Synergie seh' ich auch so. Deshalb frage ich hier ja auch nach Mit-Entwicklern. Ideal sind Leute, die neben RPG auch profundes Wissen in Sachen C++ mitbringen, nur leider gibts die nicht so oft.

Die Sachen auf SF.net habe ich mir eben mal angesehen, viele kenne ich, andere nicht. Ein RPG-Compiler ist nicht dabei. Die meisten Tools sind auch für die AS/400 gedacht, nicht für PC.

Ich hatte mich schön öfter hingesetzt, und im Web nach Lösungen für einen RPG-Compiler gesucht.

Es gibt wirklich nichts. Da waren

1. eraserhead-RPG. Hatte mit dem Autor Kontakt aufgenommen, und wie er selber sagte, war sein Compiler "nothing usefull". Das Projekt wurde eingestellt, es gibt keine verwertbaren Ergebnisse.

2. personal RPG: schlicht Schrott. Da hat jemand angesetzt, einen Compiler zu bauen, aber kein Konzept dahinter. Das Ganze ist eine Ansammlung von MS-VC++ - Projektfiles, die dann entstehen, wenn man ein neues Projekt mit Visual Studio anlegt. In der Tat hat derjenige auch sehr ordentlich begonnen, einen Umsetzer zu bauen, aber das ist es eben nicht.

Man muss sich sehr grundsätzliche Gedanken über den Zyklus, IO-Buffer, die Rolle von Datenstrukturen, das CALL-Interface, externe Bezugszahlen, UDS etc. etc machen, sonst fällt man schlicht auf die Schnauze: man braucht ein "Design".

Beispiel: Das Feld "KDNR" wird geändert. Jetzt ist KDNR aber Member einer DS, und ändert deshalb auch alle Felder mit, die an dieser Stelle der DS überlappen. Nichts Wildes in RPG, aber in C/C++ muss man sich vorher überlegen, wie man so etwas abbildet.

(ist bei rpg2cpp über shared buffers gelöst).

personalRPG hatte nichts davon: es war der Ansatz eines Umsetzers, der erkennbar nicht designed war, sondern hinkodiert. Das Projekt ist seit 2004 tot, keine verwertbaren Ergebnisse.

3. Lattice-RPG. (kommerziell). hatte selber schon mal das Vergnügen: war RPG-II und auch sonst nicht sehr lustig, überdis nur für DOS, auweia.

4. Unibol: das Abbild einer /36, schöne Sache, aber teuer.

5. Baby/400: ein Einplatzsystem, kommerziell


Mehr kenn ich nicht.

Wenn irgendjemand ein Projekt kennt, das nicht hierbei ist, immer her damit. Aber soweit ich es sehe, ist rpg2cpp z.Zt. das einzige lebende opensource Projekt in Sachen RPG. Und ich bin damit weiter, als die anderen opensource-Projekte bislang gekommen waren:

1. hochpräzise Artihmetik. In C/C++ gibt es keine Chance, die Genauigkeit aus RPG oder Cobol über die Standarddatentypen zu erreichen. Man kann noch nicht mal 1,99 korrekt darstellen, oder gar 1,000000001 und 2 richtig addieren.

Dieses Problem ist in rpg2cpp perfekt gelöst: absolute Präzision bei bis zu etwa 2000000000 Stellen (in Worten: ca zwei Milliarden Stellen Genauigkeit).

Ist für die Praxis natürlich Blödsinn, zumal die Laufzeit sicher suboptimal wäre :-))

Aber darum gehts nicht: rpg2cpp bietet _exakte_ Artithmetik.

Auch der Zyklus ist vollständig abgebildet. Zwar sind die meisten Routinen noch leer, aber sie sind da, sie sind an der richtigen Stelle und sie werden zur richtigen Zeit ausgeführt. Sie müssen nur noch auskodiert werde, eine reine Fleissaufgabe: die Programmlogik ist implementiert.

Wer zum Design Details will, kann das hier nachlesen:

http://developer.berlios.de/docman/?group_id=5256

Als Sprache "English" wählen und "go" klicken. Dort wird das grundsätzliche Design beschrieben, und wie der C++-Sourcecode später einmal aussehen könnte.

Wer sich die aktuelle (pre-Alpha) Version runterlädt, findet ein "Cycle.gif", auch für gestandene RPG-Programmierer interessant: es passieren Dinge im Zyklus, von denen viele nicht wissen.

Und wer jetzt meint: "ich programmiere nicht im Zyklus", der sollte erst recht mal reinsehen. Denn die Frage, wann z.B. H1-H9 verarbeitet werden, welche Auswirkungen *INRT im Gegensatz zu *INLR hat, wann PARM/PLIST genau verarbeitet wird, und eine ganze Reihe anderer Features hängen vor allem vom vielgeschmähten Zyklus ab: er beschreibt ja nicht nur die typische Verarbeitung einer Input Primary-Datei, sondern das gesamte Verhalten einer RPG-Applikation.

Naja, da geht es jetzt vielleicht etwas mit mir durch, aber wer einen RPG-Compiler schreiben will, kommt an diesen Dingen nicht vorbei. Sie sind schlicht die "Conditio sine qua non".

Und deshalb sind ie anderen Opensourceprojekte vermutlich gegen die Wand gelaufen: es hat sich keiner ausreichend mit diesen Dingen befasst.

Gruss
emax

[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