rpg2cpp - Opensource Entwickler gesucht

[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

[Fuerchau]

*ALRTBL *EDTD
*BNDDIR *EXITRG
*CHTFMT *FCT
*CLD *FILE
*CLS *FNTRSC
*CMD *FNTTBL
*CRG *FORMDF
*CRQD *FTR
*CSI *GSS
*CSPMAP *IGCDCT
*CSPTBL *IGCSRT
*DTAARA *IGCTBL
*DTAQ *IMGCLG
*JOBD *NODL
*JOBQ *OUTQ
*JOBSCD *OVL
*JRN *PAGDFN
*JRNRCV *PAGSEG
*LOCALE *PDFMAP
*MEDDFN *PDG
*MENU *PGM
*MGTCOL *PNLGRP
*MODULE *PRDAVL
*MSGF *PRDDFN
*MSGQ *PRDLOD
*NODGRP *PSFCFG
*QMFORM *TBL
*QMQRY *TIMZON
*QRYDFN *USRIDX
*RCT *USRQ
*SBSD *USRSPC
*SCHIDX *VLDL
*SPADCT *WSCST
*SQLPKG
*SQLUDT
*SRVPGM
*SSND
*SVRSTG
*S36

und *LIB nicht zu vergessen

Mit jedem neuen Release gibts weitere und (vorallem) auch unsichtbare.

[emax]

Danke für die Liste.

Die meisten werde ich nicht braucne, und von den anderen sind mir die wichtigsten klar.

Noch Fragen: was bedeuten

*S36
*PGM
*USRIDX

Da ist mir die genaue Bedeutung nicht klar.

Gibt es für die QS36-Files extra Typen für Index-Dateien?

Fragen über Fragen ...

Gruss
emax

[Fuerchau]

*PGM ist das Programmobjekt (also die .exe).
*S36 steht für eine /36-Umgebung
*USRIDX ist ein Index, der nur per API's ansprechbar ist (so eine Art HashMap).

[emax]

Danke nochmal, hilft mir weiter.

Gruss
emax

[Pikachu]

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

Hm? Die Bibliothek QSYS ist doch auch als Objekt in der Bibliothek QSYS vorhanden.