Module

Evolution of RPG

Ein Segen, kann oft auch zu einem Fluch werden. So ergeht es schon seit Jahren vielen IBM i RPG und Cobol Anwendungen, die durch den Segen der Abwärtskompatibilität auch 2019 auf dem neuesten Betriebssystem noch so laufen, wie sie teilweise schon seit über 40 Jahren auf den Vorgängermaschinen der AS/400 schon gelaufen sind.

I.d.T. habe ich Kunden, die noch einige RPG-II Anwendungen fahren, die Mitte der 70er Jahre entwickelt wurden und diese funktionieren immer noch problemlos.

Dieser vermeintliche Segen des Investitionsschutzes, den man so auf keinem anderen Betriebssystem findet, mutierte aber schon oft zu einem Fluch und tut das auch heute immer noch.
Denn irgendwann kommt ein neuer IT Leiter oder Geschäftsführer bzw. Vorstand in das Unternehmen und findet “uralte” Programme vor. Leider wird dann in vielen Fällen nicht zuerst gefragt, wie die Effektivität dieser Anwendungen aussieht, sondern es fallen nur die Punkte auf, die diese “alten” Programme nicht können und die “moderne” Programme standardmäßig beherrschen und so nimmt das Übel seinen Lauf…

Leider wurden und werden sehr oft die vorhandenen Programme nicht auf den aktuellen Stand der Technik angepasst, weil ja alles wunderbar funktioniert. Aufgrund des hektischen Tagesgeschäfts kommen die IBM i Entwickler oft auch gar nicht dazu ihre eigenen Kenntnisse entsprechend auf dem Laufenden zu halten und so entwickeln auch heute noch zahlreiche RPG und Cobol Entwickler, wie vor 10 oder 20 Jahren.

Mit meinem neuen Online Kurs “Evolution von RPG” bringe ich alle RPG Entwickler, die nicht auf dem neuesten Stand sind, Schritt für Schritt in 4 Etappen auf eben diesen.
An einem durchgängigen Beispiel betrachten wir uns Schritt für Schritt die Evolution von RPG. Von RPG/400 mit seinem Spaltenformat und Zyklus über das ILE RPG mit den Anfängen von /Free RPG, embedded SQL, Modulen und Serviceprogrammen bis zum heutigen Total Free RPG mit einem Schichtenmodell und Unit Tests, wie man es auch im .NET, Java und Javascript Umfeld heute benutzt.

Schnelle Web Services in RPG und Cobol

REST Service mit native I/O

Ein Bild sagt mehr, als tausend Worte.

In unserem Beispiel hier oben, kann man wohl eher sagen, ein bisschen Code sagt mehr, als tausend Worte, denn was Sie hier sehen ist ein nativer RPG Web Service, welcher als ILE Objekt auf der IBM i kompiliert wurde und diese Ausgabe im Browser erzeugt:

Ausgabe im Browser

Dieses einfache “Hallo Welt” Beispiel zeigt gleich mehrere Stärken von IceBreak, dem einzigen nativen Web- und Applikationsserver für IBM i, der gerade deshalb so unglaublich schnell ist.
Die Vorteile und Stärke von IceBreak liegt nämlich nicht nur in seiner Laufzeit Geschwindigkeit, sondern vor allem bei der Geschwindigkeit, in welcher RPG und Cobol Entwickler native Web Services auf der IBM i erstellen können. Wie man in dem Beispiel schön sehen kann, handelt es sich um ganz normalen RPG Code.
Es spielt auch keine Rolle, ob Sie SOAP oder REST Webservices entwickeln möchten. Auch ist es kein Problem SOAP oder REST Services von anderen Plattformen direkt in Ihren RPG und Cobol Programmen zu verwenden!

Natives RPG und Cobol

IceBreak erweitert RPG und Cobol bzw. jegliche IBM i ILE Sprachen, um zusätzliche Funktionen, sowie die Möglichkeit ganz einfach und direkt HTML5 Code oder XML/JSON Daten auszugeben bzw. zu lesen. So holt sich die Funktion “reqNum” direkt den genannten Parameter aus der Browser URL, sodass dieser im RPG Programm verwendet werden kann.
Wie Sie in diesem Beispiel auch direkt erkennen können, versteht IceBreak auch “klassisches” RPG, welches spaltenorientiert programmiert werden und statt embedded SQL auch native I / O (F Bestimmungen) verwenden kann. IceBreak versteht jegliches RPG und Cobol bzw. CL oder C/C++, welches die IBM Compiler umwandeln können!

Im nächsten Beispiel sehen Sie einen vollständigen Total Free RPG REST Service, welcher die IceBreak Erweiterung noxDB verwendet, um direkt via SQL Befehl JSON Dokumente zu erzeugen:

REST Service in Total Free RPG mit noxDB

Heraus kommt das:

ILE Web- und Applikations Server

IceBreak heißt der schnellste Web- und Applikationsserver für die IBM i ILE Umgebung. IceBreak ist deshalb so schnell, weil er selbst in ILE (C++ und RPG) programmiert ist und daher native auf IBM i läuft und jedes Programm, welches Sie damit entwickeln in ein natives ILE Objekt umwandelt.
Aus diesem Grund brauchen RPG und Cobol Entwickler sich auch nicht auf andere Programmiersprachen oder Tools einzulassen, denn sie können wie gewohnt ihre Anwendungen weiterentwickeln, jedoch als SOAP oder REST Webservices bzw. Clients verwenden.

Ach so – Sie wollen gar keine SOAP oder REST Services oder Clients in RPG entwickeln, sondern schnelle Web Anwendungen? Dann sollten Sie sich IceBreak erst recht anschauen, denn mit IceBreak entwickeln Sie die schnellsten ILE Web Anwendungen für IBM i – direkt mit Ihrem RPG oder Cobol Know how!
Lesen Sie hierzu auch die Neuigkeiten

Sie sind interessiert?
Kein Problem. Dann erfahren Sie hier mehr zu IceBreak oder Laden Sie sich Ihre kostenlose Community Edition direkt herunter.

Hier geht es zur IceBreak Produktseite

Laden Sie Ihre kostenlose Community Edition direkt hier herunter

oder schreiben Sie mir einfach eine Email und ich führe Ihnen IceBreak live vor.

Ich freue mich auf Ihren Kontakt. 
Email: mal@mlitters.com 
oder rufen Sie mich einfach an.

Verpassen Sie auch nicht meinen kostenlosen WebCast zum Thema:

Kostenlos aber nicht umsonst! Webcast – Web Anwendungen und Web Services mit RPG und Cobol!

Völlig losgelöst – lose Kopplung extrem!

Früher war nicht alles besser!

Als Beispiel seien (RPG) Programme genannt, die den kompletten Code in einer Quellcode Datei beinhalteten.

Das waren und sind dann schnell mal einige tausend Zeilen Code, die da im Laufe der Zeit zusammenkommen.
Im Normalfall alles mit globalen Variablen (zumindest bei RPG) und jeder Menge Bezugszahlen und Goto’s.

Solche Programme zu analysieren oder gar anzupassen ist immer wieder ein aufwendiges und meist riskantes Unterfangen – selbst für die Leute, die sie ursprünglich erstellt haben, wenngleich diese meist schon nicht mehr im Unternehmen sind.

Genau aus dem Grund hat sich in der Softwareentwicklung die Idee der Modularisierung durchgesetzt, damit man große Monolithen Programme in kleinere Module „zerhacken“ kann, welche dann nicht nur leichter zu lesen und zu ändern sind, sondern auch leicht wiederverwendbar sind, denn neben dem Problem der Unübersichtlichkeit kommt ja noch dazu, dass bei älteren Programmen, Code oft in mehrere Programme kopiert wurde und nach 10-20 Jahren auf die unterschiedlichsten Arten mutiert ist.

Im Falle von IBM i und RPG kam zunächst die Anweisung CALL ins Spiel, welche es möglich machte Programme aus anderen aufzurufen und Parameter in beide Richtungen zu schieben, allerdings zum Preis von Speicherauslastung und Geschwindigkeit.
Mit Einführung von ILE Mitte der 90er Jahre kamen dann die (Sub)Procedures und Serviceprogramme hinzu, die eine völlig neue Arbeitsweise ermöglichten und leider bis heute noch nicht überall im Einsatz sind.

Plötzlich konnte man auch in RPG mit lokalen Variablen arbeiten und sich an die Programmiermuster anlehnen, die in der restlichen Welt schon zum Standard gehörten.

Eine lockerere Bindung zwischen den einzelnen Programmteilen mit einer sehr hohen Geschwindigkeit sind die Belohnung, wenn man sich auf diese Art zu Entwickeln einlässt. Dennoch bestehen auch zwischen Programmen und Serviceprogrammen noch Bindungen, die bei Änderung z.B. des Interfaces berücksichtigt werden müssen.

In anderen Programmierumgebungen ist dies nicht anders. Ob .NET, Java, JavaScript oder was auch immer. Um auch noch dieses letzte bisschen Bindung los zu werden, haben sich Entwickler auf der ganzen Welt viele Gedanken gemacht und sind letzten Endes auf das Konzept der sog. Microservices gekommen, welche es möglich machen, Funktionalität so zur Verfügung zu stellen, dass sie nicht nur modular, skalierbar, schnell, sicher und plattformunabhängig ist, sondern auch ohne jegliche statische Bindung auskommt.

Dank IceBreak, dem einzigen nativen ILE Webserver und Applikationsserver, steht diese Möglichkeit auch allen IBM i Entwicklern zur Verfügung. Ob in RPG, Cobol, C, C++ oder CL entwickelt wird. Jegliches ILE Serviceprogramm lässt sich mit IceBreak als Microservice nutzen.

IceBreak übernimmt dabei auch die Rolle des zentralen Microservice Routers. D.h. jegliche Anfragen von außen kommen mittels Parameter und werden dabei i.d.R. als JSON Dokument oder in der URL übergeben.

Dadurch kann sich das Interface einer Funktion ändern, ohne, dass man irgendwelche Programme zwangsläufig umwandeln muss.

Nehmen wir als Beispiel den Service „msProduct“, der über die Procedure „getRows“ verfügt und uns Produkte aus der Tabelle (PF) PRODUCT in Bibliothek IceBreak zurückgibt:

https://as400:60060/router/msProduct/getRows?payload={

                        “start”: 11,

                        “limit”: 20,

            }

Erweitert man das Interface jetzt z.B. noch um einen Suchparameter:

https://as400:60060/router/msProduct/getRows?payload={

                        “start”: 11,

                        “limit”: 20,

                        “search” : “sony”

            }

müssen alle Programme, die den Service bisher aufgerufen haben in keinster Weise angepasst werden, sofern sie den neuen Parameter nicht benötigen.

Positiver Nebeneffekt dieser Programmierweise:

Diese Services lassen sich von überall aufrufen. Ob RPG Programm oder .NET Dienst, Desktopprogramm, aus Webanwendungen oder mobilen App’s.

Sie sind an einer Zusammenarbeit oder Beratung in diesem Bereich interessiert?
Kein Problem.
Schreiben Sie mir einfach.

Ich freue mich auf Ihre Mitteilung unter 
Email: mal@mlitters.com

oder rufen Sie mich einfach an.