View Full Version : Total free rpg
camouflage
25-10-19, 09:26
... wenn wir schon beim Stöffche sind, geb ich als Simbel meinen #MeToo-Senf auch noch dazu.
Wir sind schon lange nicht mehr auf Green Screen, CL, RPG und Cobol beschränkt, viel mehr kann man eine ganze Reihe von modernen Programmiersprachen (JAVA, Phyton, Ruby, PHP, ... R) und Technologien wie Webservices WATSON, Web-APIs etc. auf der IBM i einsetzen.
Den Node.js Hype haste noch vergessen. Glaubt man den Umfragen gibt es weltweit doppel so viele Javascript-Coder als C-Programmierer. Ueber Standards, Usability und Techniken will ich mich nicht auslassen, aber ist offensichtlich Fakt. Schon mal geschaut wie lange diese "modernen" Sprachen bereits auf dem Markt sind?
Ja lebt denn der alte RPG-Michel noch? Ja er lebt noch, aber nimme lang - zumindest, wenn es um Lochkartenprogrammierung geht. "Never shoot a running horse" - einem Verantworlichen klar zu machen, er soll seine Anwendung modernisieren, ohne gleich einen sichtbaren Erfolg zu haben, ist ein hartes Stück Arbeit. Da erscheint doch ein Big-Bang mit einer sexy Java-Schiessmichtot-Lösung auf den ersten Blick gleich viel attraktiver.
Diese Diskussionen kennt glaube ich jeder IBMi Shop, wenn es um Code-Redesign geht.
Ich habe da den konkreten Fall erlebt, dass ein RPG-Entwickler das Unternehmen nur deswegen verlassen hat, damit er sich mit dem neumodischen Profound-Kram nicht beschäftigen muss.
Das hat er richtig gemacht, weil am falschen Platz. Man kann sich über ProfoundUI als RPG-Version streiten, aber schlussendlich findet man sich derart zurecht (Bascis), dass der Unterschied zur Greenscreen-DDS nicht allzu gross ist.
Mit Node.js sieht es anders aus, aber hier hängt es vom Willen zu lernen ab. Und als IT'ler ist man hier ein bisschen mehr gefordert. Sonst wäre Kartoffel planzen eine Alternative, Lohneinbusse inklusive. Inwiefern Node ein Hype ist wird sich zeigen, meine Erfahrungen mit EGL genügen mir.
Wer sich einen Einblick geben will, wie man ein RPG-Programm in Node.js auflösen kann, dem empfehle ich einen 12 Min Break mit diesem Video: https://bit.ly/2Pi3nnm
Zurück zum #MeToo Senf:
Was soll IBM denn machen? Sie können gar nicht anders. Als die AS/400 an den Start ging, standen PC/Server-Anwendungen noch in den Kinderschuhen. Mit den grafischen Anwendungen hat sich vieles geändert und der Spieltrieb ist halt auch in den Unternehmen eingezogen. Klickibunti, wie Holger zu sagen pflegt. Im Zeitalter des Internets, Globalisierung und indischen Programmieren (Brain Drain aDaBa) hat sich vieles geändert. Ich hätte mir gewünscht, IBM hätte der jetzigen IBMi explizit eine grafische Entwicklungsumgebung für RPG mitgegeben, änlich wie sie jetzt von Dritten angeboten werden - es hätte vieles gebracht.
"Never shoot a running horse" - mach mal einem CEO klar er soll seine Anwendung modernisieren, ohne gleich einen sichtbaren Erfolg zu haben. Da ist doch ein Big-Bang mit einer sexy Java-Schiessmichtot-Lösung gleich viel attraktiver und für's Renommée ist auch noch was getan.
Diese Diskussionen kennt glaube ich jeder IBMi Shop, wenn es um Code-Redesign geht.
... da hat der CEO ja sogar recht.
Redesign muss in Einzelschritten vollzogen werden und sich in messbaren Vorteilen in überschaubaren Zeiträumen nachweisen lassen können (wobei äußerlich aufhübschen für mich noch kein Redesign ist, aber Luft verschaffen kann).
Ansatzpunkte sind für mich dabei Wartungskosten, Stabilität, Wartbarkeit und Änderbarkeit der Software. Altanwendungen sind nicht schlecht, weil sie mit "unmodernen" Methoden erstellt sind, das interessiert einen Anwender grundsätzlich garnicht! (Selbst Programmierern ist es egal, dass Windows grausame C Programme enthält).
Altanwendungen haben zumeist unzählige, mit heißer Nadel erstellte Änderungen, die die Qualität der Software in einem langen Prozess minimiert haben. Die Auswirkungen auf den Wartungsaufwand sind zumeist unbekannt, weil dieser nur unzureichend oder nicht erfasst wird. Voraussetzung für Redesing ist immer zuerst ein geordneter Software Erstellungsprozess mit messbaren Aufwands Metriken auf Einzelobjekt Ebene.
Erste Folge davon ist, dass Programme mit hohem Änderungsaufwand als wirtschaftlicher Totalschaden erkannt und neu geschrieben werden. Hierbei kann man dann auch bessere Methoden, Werkzeuge und erweitertes Wissen einsetzen, so man denn hat - nur so bekommt man umfassenden Vorteil.
Sieht man bei allen verbleibenden Änderungen einen festen Prozentsatz des Aufwandes für Redesign vor (Beseitigung toter Code, Verbesserung Lesbarkeit durch rename kryptischer Bezeichner, Verbesserung Modularisierung, Verbesserung Dokumentation...), geht der Aufwand zunächst um diesen Prozentsatz hoch, sinkt aber mittelfristig relativ schnell durch die verbesserte Wartbarkeit häufig geänderter Komponenten.
Freigewordene Kapazitäten werden dann in Baustellen investiert, die sich erst in längeren Zeiträumen sichtbar auswirken (hierzu gehören Restrukturierungsmaßnahmen im Bereich der Datenbank.
Wichtig ist in diesem Prozess, dass klare Zieldefinitionen vorliegen müssen, damit nicht aus Unkenntnis neue Altlasten produziert werden.
D*B
Was die IBM machen soll?
Die Frage ist doch eher: Was hätte die IBM denn machen sollen!
Auch das ist schon vielfach diskutiert und von der IBM nie umgesetzt worden.
Gibt es kostenlose oder gesponserte i's an den Unis so wie für Microsoft und Linux-Produkte?
Auf welcher Plattform lernen heute Studenten während des IT-Studiums?
Da ist der Zug an IBM mächtig vorbei gefahren. Statt sich überall selber zu versuchen (Beispiel OS/2) hätte man Kooperation ggf. auch mit Microsoft suchen sollen.
denn PCSupport und dann CA kamen ja doch zügig. Aber dann blieb es bei 5250 stehen. Selbst die 5250-Druckemulation schafft heute immer noch kein A4.
Was hätte aus VisualAge for RPG werden können?
Was hätten wir heute, wenn die grafische Oberfläche von CA nicht versandet wäre?
Aber was hilft es dem allem nachzutrauern. Versäumtes lässt sich in diesem Umfeld sogut wie gar nicht mehr aufholen.
"Was man 20 Jahre verschlafen hat, kann man das nicht in 2 Tagen aufholen!
Jetzt muss man Geld und Zeit in die Hand nehmen.
Was die finanziellen Risiken angeht, so ist es wahrscheinlich günstiger und risikoloser die aktuellen Anwendungen zu analysiseren und modernisieren als auf irgend ein Standard Produkt zu gehen, das hinten und vorne nicht passt."
Auch dem kann ich zustimmen, allerdings find ich, dass die IBM da nicht unschuldig ist.
Denn wo sind denn die "Standard-Produkte" auf die man gehen könnte?
Auch die CEO's unterliegen inzwischen einem Generationswechsel und wünschen sich inzwischen mehr der "klickibunti"-Apps, dazu noch am besten gleich Mobile aus dem Flugzeug per Wisch bedienbar.
"Die IBM i hat im übrigen noch andere Vorteile:
- Security (most securable System - wenn man das allerdings nicht einrichtet ...)
- Sogut wie keine Ausfallzeiten
- Integrierte Datenbank mir dem geringsten Betreuungsaufwand, auch wenn man massiv mit SQL arbeitet. Allerdings sollte man dann auch verstehen, wie Datenbank funktioniert und sich nicht beschweren, wenn plötzlich "Schlampereien", die früher durchgegangen sind "bestraft" werden.
- Den wenigsten Bestreuungsaufwand verglichen mit anderen Systemen."
Dann frag doch mal die Entwickler warum die lieber mit Windows und SQL-Server entwickeln?
Der aktuelle AOD.Net-Treiber der AS/400 unterstützt immer noch nicht das Entity-Framework (EF6)!
Den gibt es nur für die DB/2 im DB2-Connect-Paket, der auch noch zusätzlich lizenzpflichtig und nicht gerade preiswert ist.
Da hat es die Click+Drop-Fraktion mit dem SQL-Server erheblich leichter mal eben eine nette App zu entwickeln.
Ich persönlich arbeite gerne mit den DevExppress-Tools für Web/Forms die eine großartige EF6-Unterstützung bieten. Nun leider wird die DB2 for i eben nicht unterstützt, da muss man vieles selber programmieren, was einem EF6 sonst abnimmt.
Von MVC will ich hier gar nicht reden.
Und was SAP angeht:
Warum gehen die Versuche mit SAP schief? Weil man sich vorher nicht genug Gedanken über die Funktionalität gemacht und SAP alles versprochen hat.
HANA ist schließlich auch nicht das Gelbe vom Ei. Ich finde den Bericht i.M. nicht wieder, aber der Tenor war, dass die DB mit nur 1 Cluster für die Anzahl Transaktionen von ca. 500 Usern zu klein dimensioniert war.
Der Rest ist Geschichte.
Wenn man mal nach "Anwendungen für i" sucht findet man i.W. nur Migrationshelferlein, also eher "i bin weg".
holgerscherer
25-10-19, 12:27
Auch das ist schon vielfach diskutiert und von der IBM nie umgesetzt worden.
Gibt es kostenlose oder gesponserte i's an den Unis so wie für Microsoft und Linux-Produkte?
Gibt es. Als Möglichkeit zumindest; Wolfgang Rother kämpft ja immer dafür. Nur die Unis oder Profs haben meist keine Zeit oder Lust. Die sind mit Windows und (eher: oder) Linux schon genug ausgelastet.
Und Du glaubst gar nicht, wie viele Studenten weltweit auf PUB400.COM ähm IBMI.ONLINE
unterwegs sind. Ganze Kurse. Nur nicht aus hiesigen Landen...
Auf welcher Plattform lernen heute Studenten während des IT-Studiums?
Da ist der Zug an IBM mächtig vorbei gefahren. Statt sich überall selber zu versuchen (Beispiel OS/2) hätte man Kooperation ggf. auch mit Microsoft suchen sollen.
Dort steht halt viel unixoider Krempel rum, weil der nichts kostet. Dafür ist Linux ja auch gut, als Lernsystem zum Spielen an der Uni. Geld können die ja nicht investieren; daher hat Sun früher das Blech samt Techniker LKW-Weise für kostenlos hingestellt. Ansonsten hätte sie nie jemand wirklich mit Solaris beschäftigt.
Dann frag doch mal die Entwickler warum die lieber mit Windows und SQL-Server entwickeln?
Weil sie in der Regel gar nichts anderes kennen. Woher auch? Daheim am PC rumgespielt, in der Uni am PC rum gespielt, in der Firma: auch...
Der aktuelle AOD.Net-Treiber der AS/400 unterstützt immer noch nicht das Entity-Framework (EF6)!
Den gibt es nur für die DB/2 im DB2-Connect-Paket, der auch noch zusätzlich lizenzpflichtig und nicht gerade preiswert ist.
Da hat es die Click+Drop-Fraktion mit dem SQL-Server erheblich leichter mal eben eine nette App zu entwickeln.
Jepp. Also auch dafür bitte einen RFE schreiben - das ist die offizielle Methode, der IBM die Meinung zu geigen, nicht irgendein deutsches Forum am Rande der Galaxie. Und es wäre auch gut, wenn viele verschiedene Leute RFEs schreiben, nicht immer die gleichen ;-)
Wenn man mal nach "Anwendungen für i" sucht findet man i.W. nur Migrationshelferlein, also eher "i bin weg".
Der ist böse, aber gut, und leider wahr. Sollen wir jetzt den Softwarehäusern verbieten, "Wegmigrationstools" zu verkaufen, sondern nur noch native Entwicklungstools und (am besten) gleich fertige Applikationen? Charmanter Gedanke, vermutlich aber nicht Mehrheitsfähig.
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
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.
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 ?
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
camouflage
06-11-19, 10:01
Es gibt auch Referenzen von IBM...
DCL-F MYFILE WORKSTN(*EXT) INFDS(DSPFBK);
DCL-DS DSPFBK;
DSP_FLAG1 CHAR(2) POS(367); // Display flags
DSP_AID CHAR(1) POS(369); // AID byte
CURSOR CHAR(2) POS(370); // Cursor location
DATA_LEN INT(10) POS(372); // Actual data len
SF_RRN INT(5) POS(376); // Subfile rrn
MIN_RRN INT(5) POS(378); // Subfile min rrn
NUM_RCDS INT(5) POS(380); // Subfile num rcds
ACT_CURS CHAR(2) POS(382); // Active window cursor location
DSP_MAJOR CHAR(2) POS(401); // Major ret code
DSP_MINOR CHAR(2) POS(403); // Minor ret code
END-DS;
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
Ah gut. Dann mache ich das so. Vielen Dank