Programmierstandards - Feedback und Ideen

[dschroeder]

Zur Klarstellung: Früher gab es nur das "Fixed Format" RPG. Vor einigen Jahren hat IBM dann das sogenannte "free format" RPG herausgebracht. Dort konnte man einigen Code in freierer Form schreiben, die Deklaration der Variablen war aber noch auf fixed format angewiesen. Danach gab eine Erweiterung zum "total free RPG", in dem dann auch alle Deklarationen im free format gemacht werden konnten. (Also Einführung der dcl- Anweisungen).
Aber auch dieses "total free RPG" hat noch eine Einschränkung: Code kann nur in den Spalten 7 bis 80 stehen.

Seit Ende November 2015 gibt es jetzt das "fully free RPG". Dort ist jegliche Spaltenbeschränkung aufgegeben. Man kann also ganz links in Spalte 1 anfangen zu schreiben und soweit nach rechts raus schreiben, bis die maximale Breite der SRCPF erreicht ist (Wir haben das bei uns auf 240 eingestellt).

Die Begriffe habe ich von den IBM Veröffentlichungen übernommen. Ich finde sie auch etwas ungewöhnlich. Aber da IBM die Free-Syntaxen in mehreren Schritten eingeführt hat, gingen denen anscheinend die Begriffe aus. Dehalb ist wohl die Rede von "free", "totally free" und "fully free".

Dieter

[Fuerchau]

Mal sehen, welche Free-Varianten es demnächst gibt und wie die heißen.
Es gibt ja keinen Grund, warum eine DCL-Anweisung unbedingt am Anfang stehen muss.
Der Compiler arbeitet ja sowieso in mehreren "Phasen".

Die nächste Option ist ein Copy, der je nach Quelltyp ein Copystrecke automatisch von RPG nach ILERPG nach FullyFree konvertiert.
Hierbei werden dann dynamisch erstellte Variablen (was ja nur im Nicht-Free geht) dann kurz davor per DCL definiert.
PLIST-Aufrufe werden in PR's konvertiert und die Call's angepasst.
KLIST's werden aufgelöst (entfernt) und die entsprechenden EA-Befehle um die Keyfelder ergänzt.
Hier brauche ich dann nicht mehr zu suchen, mit welchem Schlüssel denn nun tatsächlich zugegriffen wird.
Dann brauch ich mich um die "Modernisierung" der Quellen auch nicht mehr zu kümmern.

Nun gut, das automatische Konvertieren von Subroutinen in Prozeduren wird dann wohl nicht lange auf sich warten lassen.

[BenderD]

Nun gut, das automatische Konvertieren von Subroutinen in Prozeduren wird dann wohl nicht lange auf sich warten lassen.

... umsetzen von SUBRs nach PROCs konnte das Linoma Teil schon bevor es free gab.

D*B, der das Gedöns um free RPG nicht verstehen kann, das war für andere Programmiersprachen schon normal, bevor die meisten Programmierer aus den Windeln raus waren.

[dschroeder]

D*B, der das Gedöns um free RPG nicht verstehen kann, das war für andere Programmiersprachen schon normal, bevor die meisten Programmierer aus den Windeln raus waren.

Gerade weil die freie Eingaben für eine Programmiersprache so wichtig ist, ist es doch klar, dass sich die RPG-Programmierer dafür interessieren, wie es geht und die Forderung aufstellen, dass es vernünftig funktioniert.

Dieter

[BenderD]

Gerade weil die freie Eingaben für eine Programmiersprache so wichtig ist, ist es doch klar, dass sich die RPG-Programmierer dafür interessieren, wie es geht und die Forderung aufstellen, dass es vernünftig funktioniert.

Dieter

... warum erinnert mich das nur immer wieder an F.W. Bernstein? Die schärfsten Kritiker der Elche, waren früher selber welche.
Die Metamorphose des tiefblau gefärbten AS/400 Anhängers lässt mich immer wieder schmunzeln.
Stufe 1: der RPG Zyklus ist das Größte.
Stufe 2: RPG ist so toll, weil man den Zyklus nicht mehr benutzen muss.
Stufe 3 a: /free und /end-free ist Spitze , weil man sofort sieht, dass jetzt keine Spalten mehr kommen.
Stufe 3 b: toll, dass man Kommentare am Zeilenende nicht kennzeichnen muss
Stufe 3c: Deklarationen müssen in Spalten bleiben, das ist einfacher
Stufe 3d: embedded SQL, da kann kein free format gehen
Stufe 3e: call und eval sind das Größte
Stufe 4: toll das embedded SQL jetzt auch in Freeformat geht
Stufe 5: toll, jetzt gibt es sogar noch ein eval corr
Stufe 6: toll, jetzt braucht man nicht einmal mehr /free und /end-free schreiben
Stufe 7: toll, jetzt gibt es total free
Stufe 8: noch toller, jetzt gibt es fully free
Stufe next: jetzt warten wir auf total fully free
Stufe übernext: jetzt fehlt nur noch full total fully free
final Stufe: jetzt funktioniert sogar alles

D*B

PS: das Endergebnis hätte man auch einfacher haben können: CRTDUPOBJ CRTBNDC QSYS *CMD NEWOBJ(CRTBNDRPG), dann hätte man sich sogar eine Menge Gedöns mit Prototypen erspart und Blöcke könnte man einfach durch geschweifte Klammern darstellen (Vorsicht Elchtest: das könnte in full total fully free RPG kommen), aber das hätten die Elche wahrscheinlich nicht gemocht.

[camouflage]

Die ganze Diskussion erinnert mich an die Aussage einer befreundeten Fotografin:
"Was nützt die tollste Fotoausrüstung, wenn man nicht das Auge für das Motiv hat"!

just my 2 cts.

[Fuerchau]

Dem kann ich mich nur anschließen.
Bei den ganzen Möglichkeiten bin ich einfach froh, dass meine Programme funktionieren.
Egal ob COBOL, RPG, mit oder ohne ILE oder SQL, meine Kunden zufrieden sind und die (interne) Doku verständlich wirkt.
Dabei habe ich meinen eigenen Standard entwickelt, passe mich den Kundenwünschen aber an oder überzeuge Sie, wenn mein Weg der bessere ist.

[LordCinimod]

... warum erinnert mich das nur immer wieder an F.W. Bernstein? Die schärfsten Kritiker der Elche, waren früher selber welche.
Die Metamorphose des tiefblau gefärbten AS/400 Anhängers lässt mich immer wieder schmunzeln.
Stufe 1: der RPG Zyklus ist das Größte.
Stufe 2: RPG ist so toll, weil man den Zyklus nicht mehr benutzen muss.
Stufe 3 a: /free und /end-free ist Spitze , weil man sofort sieht, dass jetzt keine Spalten mehr kommen.
Stufe 3 b: toll, dass man Kommentare am Zeilenende nicht kennzeichnen muss
Stufe 3c: Deklarationen müssen in Spalten bleiben, das ist einfacher
Stufe 3d: embedded SQL, da kann kein free format gehen
Stufe 3e: call und eval sind das Größte
Stufe 4: toll das embedded SQL jetzt auch in Freeformat geht
Stufe 5: toll, jetzt gibt es sogar noch ein eval corr
Stufe 6: toll, jetzt braucht man nicht einmal mehr /free und /end-free schreiben
Stufe 7: toll, jetzt gibt es total free
Stufe 8: noch toller, jetzt gibt es fully free
Stufe next: jetzt warten wir auf total fully free
Stufe übernext: jetzt fehlt nur noch full total fully free
final Stufe: jetzt funktioniert sogar alles

D*B

PS: das Endergebnis hätte man auch einfacher haben können: CRTDUPOBJ CRTBNDC QSYS *CMD NEWOBJ(CRTBNDRPG), dann hätte man sich sogar eine Menge Gedöns mit Prototypen erspart und Blöcke könnte man einfach durch geschweifte Klammern darstellen (Vorsicht Elchtest: das könnte in full total fully free RPG kommen), aber das hätten die Elche wahrscheinlich nicht gemocht.

Mhm, ich verstehe gerade deine Aussage nicht so genau, was ist schlimm daran das RPG moderner wird? Als ich meine Ausbildung angefangen habe habe ich mit free rpg angefangen. Ich fand das sehr umständlich, mir persönlich gingen diese Spalten tierisch auf den Nerv! Gleichzeitig war ich froh, da mir das so definitv besser gefiel als die alte Schreibweise ohne free und end-free.

Als dann tfr rauskam war ich selig, viel angenehmer zu schreiben und zu lesen(da sind sich alle Azubis bei uns in de EDV und in der Common-D Schulung einig). Ich finde es klasse das RPG weiterentwickelt wird und mir ist bewusst das es vllt. erst in x Jahren (wenn überhaupt) den Stand einer heutigen Sprache erlangt, aber hey was solls hauptsache es gibt einen Fortschritt und warum soll man das dann nicht auch gut finden dürfen?

Selbes trifft auf DDS und Profound zu (wie dschroeder schon schrieb) Profound ist viel angenehmer zu programmieren und auch zu nutzen.

Vllt. bin ich aber auch als Azubi nur naiv und habe zu wenig durchblick xD

PS: Auch wir schreiben Programme nur rein intern für unsere Firma, arbeiten also nicht für externe Firmen. Vllt. ist das ja der Grund für die unterschiedlichen Meinungen ; )

[LordCinimod]

@dschroeder:

Ich weis nicht ob ich deine Problematik im Moment richtig verstehe, aber so wie ich das verstehe würde ich eine Maske erstellen, mit verschiedenen Records(Kundendaten, Adressdaten) dann hätte ich ein *srvpgm wo alle DB Zugriffe usw. als Prozeduren vorliegen und dann eine Control Datei wo die ganze Steuerung abläuft. Wobei es dann z.B. eine getKundendaten(Para) und eine getAdressdaten(Para) Prozedur, welche dann je nachdem deine Records befüllt. Die Prozedur getAdressdaten kann man ja auch dann in jedes Programm einbinden, die notwendigkeit eines richtigen Programmes sehe ich da gerade nicht, aber vllt. habe ich was falsch verstanden(bin ja auch noch Azubi ; )

Dazu muss ich aber noch sagen das ich durch Prüfungsstreß wegen Ausbildungsende noch nicht sehr viel praktisch experimentiert habe, hauptsächlich die Artikel gelesen und theoretisiert.

EDIT: Modul meinte ich *srvpgm welches dann per bnddir eingebunden wird.
EDIT2: Liegt das nur an meinem Browser oder werden bei euch Emoticons auch nicht angezeigt?

Grüße
Dominic

[dschroeder]

Bei mir (Chrome) werden innerhalt des Textes nur eckige Standardbildchen angezeigt. Sind wahrscheinlich deine Emoticons.

Zu deiner Antwort bzgl. MVC: So ähnlich machen wir das. Wir versuchen das meiste an Plausicode, Speichercode usw. in Tools auszulagern. Aber trotzdem muss man ja noch viel immer wiederkehrendes machen. Beispielsweise müssen wir in den Profound-Masken ja die Errormessages und Errorconditions für jedes einzelne Feld definieren (wir wollen feldspezifische Fehler haben). Meine Idealvorstellung wäre etwa folgendes:
Man will eine Kundenmaske bauen mit einigen kundenspezifischen Feldern und einem Block, in dem eine Adresse eingetragen werden soll. Dann wäre es natürlich super, wenn man einmalig einen Adresserfassungsblock incl. der Bildschirmfelder mit allen Plausis usw. bauen könnte und diesen Block dann in eine bestehende Kundenmaske integrieren könnte. Man könnte auf der Kundenmaske ja einen Container vorsehen, in dem sich das Adressformat ausbreitet. Aber das geht ja mit dem Display-File Konzept nicht. (Außerdem würde man wahrscheinlich multithreading brauchen, um das zu implementieren.).

Wenn so etwas aber ginge, hätte man noch ganz andere Möglichkeiten der Modularisierung und Wiederverwendung. (Eine Adresserfassung würde ich ja auch auf einer Lieferantenmaske benötigen).

Tja, es gibt so viele Ideen, was man noch alles brauchen könnte ...

Dieter

[Fuerchau]

Solche Beispiele lassen sich auch in Fenstertechnik lösen.
In meiner Bildmaske sind nur Ausgabefelder der Adresse.
Benötige ich eine Adresserfassung rufe ich die entsprechende Funktion auf.
Diese macht eben alles wie gerade beschrieben und liefert mir die Adresse zurück die ich anzeige.
Ebenso kann ich z.B. per F-Taste auf der Adresse die Änderungsfunktion aufrufen.
Das ist dann genau die gewünschte Modularität.

Ebenso kann man eine Adresseingabe mit einer AdressStruktur aufrufen, die gibt mir dann die Fehlernummer und ggf. das Feld für die Positionierung auf dem Fehler zurück.

Möglichkeiten gibt es auch bei DSPF sicherlich viele.
Aber wer nutzt denn noch 5250.
So was unmodernes kann man doch keinem mehr zumuten.
Hier muss .NET oder Java o.ä. eingesetzt werden. Dann läuft sowieso alles schöner, besser, schneller.

[dschroeder]

Tja, Baldur. Ich bin wirklich ein Fan der iSeries und habe 20 Jahre lang 5250-Oberflächen programmiert. Aber seit wir grafische Anwendungen auf der iSeries entwickeln, möchte ich wirklich nicht mehr zurück zur klassischen 5250-Oberfläche. Ich meine jetzt nicht mal die Frage, ob das für den Anwender schöner ist. Ich spreche rein von der Programmierung. Bei grafischen Umgebungen ist wirklich vieles so viel einfacher zu implementieren. Z.B. weniger Plausis, weil der User die Daten nicht eingibt, sondern auswählt. Weniger Probleme, noch Platz auf dem Bildschirm für neue Felder zu finden. Im Gegensatz zu 5250 ist der grafische Bildschirm ja riesig!). Und das Handling von Subfiles ist geradezu kinderleicht im Vergleich zu früher. Ich wüsste nicht, wann ich früher mal Programme mit mehr als einer Sfl auf der Maske geschrieben hätte. In unseren Profound-Masken ist das fast schon Standard, eben weil man Platz hat und es so einfach ist. Zur Klarstellung: Wir sind kein Softwarehaus, sondern Anwender. Wir verkaufen kein Profound und wir bekommen auch keine Provsion. Das ist jetzt alles nicht aus Werbezwecken gemeint. Das ist echt so!

Wenn man dann eine grafische Maske entworfen hat, findet man ein Umschalten für die Adresseingabe einfach nicht mehr so schön. Das ist dann irgendwie "nicht zeitgemäß". Sorry, ich möchte dir nicht zu nahe treten. Ich habe selber früher lange in einem iSeries-Softwarehaus gearbeitet und weiß natürlich, dass man nicht machen kann, was man möchte, sondern dass man darauf angewiesen ist, was die Kunden wollen. Wenn die 5250 haben wollen, baut man das natürlich als Freelancer.

Das mit dem Umschalten auf die Adresseingabe ist aber eben nur ein Trick, weil man es nicht richtig in die Maske integrieren kann. Ich muss zugeben, dass unsere Eclipse-Entwickler da echt mehr Freiheiten haben. Auch wenn ich Profound echt toll finde, geht da mit nativen Windows Werkzeugen echt noch mehr!

Dieter