Total free rpg

[harkne]

Hallo alle,

vielen Dank für die Antworten. RDI benutze ich heute schon für ILE-RPG.

Viele Grüße Harald

[Fuerchau]

Na denn, frisch ans Werk. Ich habe es auch schon gelernt;-).

Ich bin jetzt nur noch gespannt, wann es
- instantiierbare ILERPG-Klassen
- Dynamische Arrays / Collection / Hashtables
- Dynamische Strukturen
- Aufhebung der 16 MB-Grenze
gibt.

Oder noch viel besser:
Portierung von .Net-Core auf AS/400 => native C#/VB.Net/... auf AS/400, ASP.Net u.v.m.
Windows damit so richtig das Wasser abgraben.

[andreaspr@aon.at]

Im Großen und Ganzen kann man FREE alleine lernen wenn man möchte.
Wenn man einen Workshop haben will würde es eher dann Sinn machen wenn man diesen kombiniert.
Z.B. ILE Konzept mit Prozeduren, Prototypen, Serviceprogramme, neue Technologien von SQL in RPG nützen, wie kann ich in RPG möglichst einfach und schnell XML & JSON lesen bzw. generieren usw.
In FREE gibt es auch kein CALL 'MYPGM' mehr, sondern man muss die Programme als Prozeduren via Prototype deklarieren.
Ich kann RPG Prozeduren in CL oder auch SQL als Funktionen benützen.

Ich mache gerade einen Workshop über genau diese Themen.
Den Leuten gefällt es sehr, sind überrascht was alles möglich ist und wollen gar nicht mehr im alten Styl Entwickeln.

Alte Programme zu konvertieren ist Lobenswert, und wenn's funktioniert auch super.
Jedoch meiner Meinung nach nicht zwingend notwendig.
Normal reicht es wenn man sich darauf einigt neue Programme oder größere Änderungen im neuen Stil zu schreiben.
Alte Programme können bleiben wie sie sind.
Dadurch fällt das K.O. Argument: "Entweder alles oder nichts".

lg Andreas

[dschroeder]

Alte Programme zu konvertieren ist Lobenswert, und wenn's funktioniert auch super.
Jedoch meiner Meinung nach nicht zwingend notwendig.
Normal reicht es wenn man sich darauf einigt neue Programme oder größere Änderungen im neuen Stil zu schreiben.
Alte Programme können bleiben wie sie sind.
Dadurch fällt das K.O. Argument: "Entweder alles oder nichts".

Da schließe ich mich an. Wir setzen den ARCAD Transformer nur gezielt ein. Wenn in einem fixed format Programm eine (größere) Änderung notwendig ist, konvertiere ich das Programm und mache die Änderung dann im fully free.
Auch wenn der ARCAD Transformer ganz gut ist, benötigt jede Konvertierung etwas Nacharbeit. Deshalb konvertieren wir nur, wenn es sich lohnt. Neues schreiben wir immer in fully free.

Der Umstieg auf fully free ist eigentlich sehr einfach. Vieles wird ja einfach besser als vorher!
Der größte Knackpunkt wird wahrscheinlich wirklich die Tatsache sein, dass man das Schlüsselwort CALL nicht mehr nutzen kann, um Programme aufzurufen. Man ist gezwungen, für jedes Programm, das man aufrufen möchte, einen Prototyp zu definieren (und am besten in einer Copy-Strecke abzulegen). Das klingt im ersten Moment sehr umständlich, aber man bekommt auch etwas dafür: Durch die Prototypes werden Fehler bei Parameterübergaben stark reduziert und meistens schon zur Compilezeit erkannt.

[holgerscherer]

Na denn, frisch ans Werk. Ich habe es auch schon gelernt;-).

Ich bin jetzt nur noch gespannt, wann es
- instantiierbare ILERPG-Klassen
- Dynamische Arrays / Collection / Hashtables
- Dynamische Strukturen
- Aufhebung der 16 MB-Grenze
gibt.

Oder noch viel besser:
Portierung von .Net-Core auf AS/400 => native C#/VB.Net/... auf AS/400, ASP.Net u.v.m.
Windows damit so richtig das Wasser abgraben.

Du weisst doch, wie man RFEs schreibt? Dann ran

Allerdings würde ich das Windows-Gerödel nicht nativ auf der i haben wollen. In dem API-Grab verläuft man sich ja.

-h

[Fuerchau]

Dann hast du dir .Net-Core noch nicht angeschaut.
Das ist quasi die ursprüngliche und nun zugelassene Raubkopie von .Net, ehemals genannt Mono.
Auf Grund eines sogar amerikanischen Kartellurteils musste Microsoft die Quellen offen legen.
Somit ist aus Mono (nur .Net 2.0) nun Core geworden.

Warum also soll Core nicht auf der AS/400 ebenso laufen wie auf Linux oder sogar Android?
Man könnte damit dann mal tatsächlich zumindest aus der C#/VB.Net-Ecke auch Entwickler wieder für unsere AS/400 ködern.

[Fuerchau]

Also was die Fehlererkennung zur Compilezeit angeht, so hört es bei der Verwendung von DS'n als Parameter allerdings auf.
Bei Reference wird zumindest nicht einmal die Länge der DS geprüft.
Bei CONST/VALUE ist das noch nachvollziehbar aber nicht bei Reference.
Bisher konnte ich immer erst zur Laufzeit Tippfehler im Parameternamen erkennen, da die Folgeverarbeitung ggf. durch Pufferüberschreibungen abstürzte.
Intellisense hat zwar schon Vorteile, aber schnell ist da auch schon mal ein Name verwechselt.

Die Prüfung sollte mindestens bei DS-Parametern eine Struktur-Signatur ermitteln und prüfen.
Damit könnten schon so einige Fehler früher behoben werden.

Das selbe gilt immer noch bei SQL-Feldern.
Hier sollte eine Verpflichtung zur Compilezeit (Option?) der Existenz von SQL-Variablen einstellbar sein.
Dann würden auch hier eine Vielzahl von Tippfehlern frühzeitig erkannt werden.

[Fuerchau]

@MK
Warum denn nicht gleich mit IFS-Streams?
Dann entfällt das Ganze Membergedöhns, man kann z.B. GiT nutzen und sonstige Tools die mit IFS-Streams umgehen können.

[harkne]

Ich bin aktuell mittendrin. In meiner Informationsdatenstruktur habe ich das Unterfeld CPOS was definiert ist mit (von) 370 (bis) 371B 0.
Ich denke mal ich muss "bindec" als Datenart Schlüsselwort verwenden. Aber welche Länge muss ich angeben ? Bestimmt nicht bindec(2) oder ?

Viele Grüße Harald

[Fuerchau]

Die Frage ist, welche Wertigkeit du benötigst:
int(5) bzw. bindec(4) belegen die 2 Bytes, wobei int(5) eben +/- 32767 kann, ansonsten geht nur +/- 9999.

[harkne]

Das ist die Cursorposition aus der Informationsdatenstruktur. Einfach nur verwendet, nie darüber nachgedacht, hat ja funktioniert. Also bei 2 Stellen B 0 in der "alten" Datenstruktur gebe ich bindec(4) an, wenn ich das richtig verstanden habe ?

[B.Hauser]

Wenn Du schon dabei bist, die Datei-Status-Datenstruktur von Display-Files zu überarbeiten, würde ich Dir empfehlen 2 Felder je Uns(3), eines für Zeile (Position 370) und eines für Spalte(Position 371) zu definieren. Dann kannst Du Dir die Dividiererei sparen und Zeile bzw. Spalte direkt auslesen.

Ansonsten würde ich, falls Du beides zusammenfassen willst oder musst, Uns(5) empfehlen. (negative Werte für Zeile/Spalte gibt es nicht!)

BINDEc solltest Du auf alle Fälle vermeiden und je nachdem INT oder UNS verwenden. Bei BINDEC wird der Inhalt (intern) in gepackt konvertiert, während bei INT und UNS die Integer-Datentypen direkt verwendet werden.

Birgitta