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.

[dschroeder]

Dominik, noch eine Frage zu MVC: Ich habe den Artikel (noch) nicht gelesen. Aber hast du denn eine gute Idee, wie du die Trennung sauber hinbekommst? Wir versuchen natürlich auch, die Eingabe von der Businesslogik zu trennen. Aber vieles hängt irgendwie doch immer am Bildschirm. Es gibt ja kaum Möglichkeiten, die Dinge auf einem Display zu modularisieren. Ich meine damit, dass man z.B. auf einer Kundenmaske nicht ein weiteres Programm aufrufen kann, dass eine Adresse erfragt und sich "in den Bildschirm" einpasst. Es sind dann entweder 2 Programme mit 2 Masken oder aber ein "großes" Programm mit einer großen "Maske" (Also Kundendaten und Adressdaten). Selbst mit Profound-Mitteln ist das ja so nicht möglich. (Mal abgesehen von iFrame oder direktem Javascript).

Dieter

[dschroeder]

Eine konkrete Empfehlung habe ich aber auch noch: Wenn ihr mit Profound arbeitet, könnt ihr in Displayfiles mit langen Feldnamen (Stichwort "alias") arbeiten. Bei uns heißt ein normales Displayformat F1. Wenn es ein zweites gibt, heißt das dann F2 usw. Wenn es eine Subfile ist, heißt das Format S1. (Bei mehreren Subfiles S2, S3, usw...).

Die Felder in den Formaten habe dann ganz "normale" Namen, wie z.B. "name" oder "rechnungsbetragBrutto". Sie brauchen keine eigene Kennung als Variablen von Display-Files, da sie über die Displayfiles-Datenstrukturen angesprochen werden. Also z.B. "f1.name" oder "s1.rechnungsbetragBrutto".

Hallo Dominic,
leider ist mir bei der Beschreibung ein Fehler unterlaufen. Ich hoffe, ich habe dich nicht in die Irre geführt.
Die Formate in Display heißen bei uns nicht F1 und F2, sondern FMT1 bzw. SFL1.
F1 und S1 sind im Programm definierte Strukturen, um die Alias-Namen zu verarbeiten.
Hier ein Beispiel:
Das Displayfile heißt "sis45ad", das erste Format im Display heißt fmt1, die erste Subfile im Display heißt sfl1.

Dann wäre folgendes die Deklaration der Display-File im RPG:

       dcl-f sis45ad WORKSTN handler('PROFOUNDUI(HANDLER)') alias qualified
                                             sfile(sfl1:f1.s1_satznr);

Die Datenstrukturen für die Formate sind dann folgendermaßen zu deklarieren:

// Qualifizierte Datenstrukturen für Bildschirm-Handling:       
dcl-ds f1 likerec(sis45ad.fmt1:*all);       // Alle Felder des normalen Formates
dcl-ds s1 likerec(sis45ad.sfl1:*all);       // Alle Felder von sfl1

Die Strukturen verwenden wir dann beim Zugriff auf das Format oder die Subfile,
also z.B.:

exfmt sis45ad.fmt1 f1;
oder
chain satznr sis45ad.sfl1 s1;

Der Zugriff auf die Felder erfolgt dann qualifiziert. Wenn es also in der Subfile ein Feld rechnungsbetrag gibt und im normalen Format ebenso, kann man die Felder so ansprechen:

if f1.rechnungsbetrag > 0, 
   ...

bzw.

if s1.rechnungsbetrag > 0, 
   ...

Das Schöne an den langen Namen ist insbesondere, dass man alle Attribute mit klaren Begriffen benennen kann. Wenn der Rechnungsbetrag sichtbar/unsichtbar geschaltet werden soll, würde man die Variable dafür im Display eben "rechnungsbetrag_visible"
nennen.

Entschuldige meine langen Ausführungen, falls du das sowieso schon alles wusstest. Aber ich dachte, bevor du lange rumprobierst...

Übrigens: Das Schlüsselwort *all bei der Deklaration der Datenstrukturen geht noch nicht so lange. Ich glaube, man braucht das OS Version 7.1 und ein bestimmtes Technology Refresh.

Dieter

[LordCinimod]

Danke Dieter, ich bin noch nicht dazu gekommen mich damit zu beschäftigen, stecke gerade mitten in meiner Prüfungsphase und komme daher im Moment nicht viel zum rumprobieren und programmieren : (

Vielen Dank aber für deine Korrektur und die Erklärung dazu, werde mir das anschauen sobald ich wieder ein bisschen Luft habe(voraus. nächste Woche wenn alles gut geht ;D )

[Pikachu]

Das erinnert mich etwas an die Evolution eines Programmierers ...