Markus Litters

IBM öffnet POWER Prozessor

Ende August hat IBM auf dem Open Source Summit der Linux Foundation, den nächsten Schritt in Richtung Open Source Company angekündigt und die Instruction set architecture – kurz ISA – seiner POWER Prozessoren als Open Source veröffentlicht.

Nachdem sich IBM vor 6 Jahren durch die OpenPOWER Foundation bereits erstaunlich stark dem Markt geöffnet hat, ist dies nun der nächste, große Schritt und ermöglicht es so anderen Herstellern, eigene POWER Prozessoren zu bauen und mit eigenen Innovationen zu versehen.

Gerade für die IBM i Kunden ist dies auch ein wichtiger Schritt, denn durch die Offenlegung des Codes, ist es nun auch anderen Herstellern möglich einen Prozessor zu bauen, auf dem IBM i lauffähig ist.

Wie das lizenztechnisch nachher aussieht, bleibt abzuwarten, jedoch ist es ein wichtiger Schritt in Richtung Zukunftssicherheit des IBM Betriebssystems.

Fakt ist, dass durch diesen Schritt IBM derzeit die einzige Firma ist, die, u.a. durch den Kauf von Red Hat, eine komplette Open Source Lösung von der Prozessor Hardware bis zum Betriebssystem und der Middleware anbieten kann.
Immer mehr Unternehmen legen darauf besonders großen Wert, vor allem wegen den Sicherheitsaspekten. Die zahlreichen Sicherheitsvorfälle der letzten 2 Jahre (zuletzt der Urgent/11 auf VxWorks), vor allem auch auf Hardware- und Betriebssystem Ebene, zeigen, dass die Hersteller hier ebenfalls noch viel lernen und tun müssen. Dank der Öffnung des Quellcodes kann IBM somit auch von einer stetig wachsenden Community profitieren, die dabei hilft, mögliche Sicherheitslücken zu entdecken und zu schließen.

IBM i 7.4 und TR6 für 7.3

Sicherlich haben Sie schon auf anderen Kanälen von dem Announcement von IBM i 7.4 gelesen.
I.d.R. finden sich derzeit jedoch hauptsächlich Informationen über die neue Funktion “IBM DB2 Mirror for i” und nur recht wenige Infos zu den div. anderen Verbesserungen und Erweiterungen, die übrigens auch zum großen Teil für IBM i 7.3 mit dem neuen Technology Refresh 6 zur Verfügung stehen.

Alle, die meinen Newsletter schon etwas länger beziehen oder meine Artikel im TechKnowLetter lesen, wissen, dass ich mich seit Beginn der Open Source Implementierung von IBM für IBM i mit den div. Frameworks und Tools beschäftigt habe. Allen voran mit Node.js.
Gerade hierfür gibt es nun einige Neuigkeiten.

Die DB2 Provider idb.connector und idb-pconnector wurden jetzt in der Version 1.x als NPM Pakete freigegeben.

https://www.npmjs.com/package/idb-connector

https://www.npmjs.com/package/idb-pconnector

U.a. hat IBM den Quellcode nun auf GitHub verschoben. Verwunderlich ist, dass die Downloadzahlen bei NPM so drastisch differieren. Hat die “klassische” Callback Variante idb-connector stolze 15.644 Downloads in der Woche, so hat die promise basierte (also weiterentwickelte) Version gerade einmal 5 Downloads. Sollten Sie Fragen zu den Vorteilen von Promises gegenüber der sog. Callback Hölle haben, stehe ich Ihnen gerne zur Verfügung….

Interessant ist auch die Portierung des ODBC Treiber aus i Access. Damit lassen sich (Alt)Anwendungen, die noch auf ODBC Basis arbeiten problemlos auch auf die IBM i portieren.
Der aktuelle Weg sollte aber klar hin zu REST basierten Services sein, die nicht nur erheblich schneller als ODBC sind, sondern auch flexibler und u.a. den Zugriff von mobilen Plattformen erlauben.

Das Python Ökosystem hat ebenfalls enormen Nachwuchs bekommen. Vor allem im Bereich Machine Learning hat IBM fleißig Pakete portiert.
So stehen jetzt u.a. bcrypt, cryptography, numpy, pandas, scikit-learn und scipy zur Verfügung. Vielen Dank IBM – die können wir in aktuellen Projekten gerade sehr gut gebrauchen.

Apropos Machine Learning – hier hat IBM mit der Ankündigung von “R” als weitere Programmiersprache, die nach Python klar auf Platz 2 im Bereich Machine Learning steht, ein deutliches Zeichen gesetzt, wo die Schwerpunkte der IBM i Anwender aktuell und in Zukunft liegen. Endlich können wir den Workload, den wir all die Jahre auf andere Plattformen auslagern mussten, wieder zurück auf die IBM i holen.

Zu all diesen Tools, Sprachen und Paketen gesellen sich noch weitere hinzu, die uns die Arbeit und damit das Leben künftig erheblich erleichtern. Der Midnight Commander wurde von mir ja schon vor einiger Zeit vorgestellt (u.a. im TechKnowLetter des Midrange Magazins) und mittlerweile so ziemlich bei all meinen Kunden installiert und genutzt. Damit wird die Arbeit mit IFS Dateien und Verzeichnissen endlich angenehm. Midnight Commander ist ein Notron Commander Clone, der in der Unix/Linux Welt sehr verbreitet ist und nun auch native auf IBM i (in PASE natürlich) läuft und einen sehr schnellen Zugriff auf IFS Dateien erlaubt.

Mit redis haben wir nun endlich auch die Möglichkeit zahlreiche Node.js Projekte direkt zu portieren und auf IBM i laufen zu lassen, da viele diesen In-Memory Datenspeicher intensiv nutzen.
Apache ActiveMQ bietet uns einen bewährten Message Broker, der die unterschiedlichsten Protokolle unterstützt, wie z.B. WebSockets, REST, MQTT, u.v.m.
U.a. die Unterstützung von Python, .NET, c++ und vielen weiteren Programmiersprachen hat ActiveMQ zum populärsten Open Source Messaging Server werden lassen.

Zum Teil stehen diese Pakate schon länger zur Verfügung, zum Teil sind sie noch nicht erhältlich. So oder so lohnt es sich, von Zeit zu Zeit nachzusehen, welche Pakete es zwischenzeitlich gibt, denn die Auswahl wird immer größer.

Weitere Infos zum neuen IBM i 7.4 folgen in Kürze.

Windows bekommt einen Linux Kernel und kann mit Windows Terminal auf IBM i zugreifen

Die BUILD 2019 Entwicklerkonferenz von Microsoft hat wieder unzählige Neuigkeiten zu Tage gebracht.

Eines der spannenderen Themen dürfte sicherlich der neue Linux Kernel sein, den Microsoft nun in Verbindung mit dem Windows Subsystem für Linux (WSL) 2 im Sommer bringen wird.

Statt, wie bisher in WSL 1, einen sog. Translation Layer zu verwenden, der die Linux Systemaufrufe in Windows Systemaufrufe übersetzte, nutzt man künftig einen eigenen, echten Linux Kernel, der auf der jeweils neuesten LTS Version des Linux Kernels aufsetzen wird.
Damit bekommt Microsoft die bisherigen Probleme mit Inkompatibilität und Performanceproblemen in den Griff, mit denen man z.T. leben musste, wenn man eine der zahlreichen Linux Distributionen aus dem Windows Store unter Windows 10 oder Windows Server nutzte.

Durch den eigenen Kernel, ist es kein Problem mehr Linux Treiber und echte Linux Docker Container unter Windows zu betreiben, was mit Sicherheit einer der Hauptgründe für diesen Schritt ist, denn die Container Technologie ist schon lange kein Hype mehr, sondern im täglichen Betrieb vieler Firmen unabdingbar.

Mit WSL 2 werden künftig keine virtuellen Maschinen mehr für Docker Container unter Windows benötigt, sondern können direkt in WSL 2 ausgeführt werden.
Der Kernel wird, wie bei Microsoft mittlerweile üblich, komplett Open Source sein und jeder kann sich seinen eigenen Kernel umwandeln und nutzen.

Soweit bisher bekannt, wird WSL 2 auf einer sehr leichtgewichtigen, speziellen, virtuellen Maschine aufsetzen, die in Windows integriert sein wird. Dadurch wird sie schneller gestartet, verbraucht weniger Speicher und wird dennoch nur ausgeführt, wenn sie gebraucht wird.

Die vorhandenen Linux Distributionen im Windows Store sollen mit WSL 2 alle erheblich schneller laufen und vollständig kompatibel sein.

Die Entwicklung von plattformübergreifender Software unter Windows wird damit noch leichter, als sie bisher schon war. Aktuell ist es mit WSL 1 schon möglich Visual Studio Code unter Windows auszuführen, damit jedoch Node.js Anwendungen im Linux Subsystem zu testen und zu debuggen.

Im Hinblick auf die Entwicklung von Node.js Anwendungen für IBM i eine echte Erleichterung.

Den vollständigen Blogpost von Jack Hammons, Program Manager der Linux Systems Group, zur Ankündigung finden Sie hier:

Parallel bekommt Windows eine neue App spendiert:

Windows Terminal

Damit braucht man künftig keine separaten Tools wie Putty u.ä. zu installieren und kann in verschiedenen Tabs auf verschiedene Hosts wie z.B. IBM i, Ubuntu aber auch PowerShell oder den klassischen CMD Prompt zugreifen.

Der Open Source Tradition Microsofts folgend, steht der C++ Code von Windows Terminal natürlich schon unter GitHub bereit
https://github.com/Microsoft/Terminal
Dieser kann bereits jetzt compiliert und somit eingesetzt werden.

Im Sommer wird es dann eine Version im Windows Store geben, für alle, die die Vorabversion testen wollen, jedoch nicht selbst umwandeln möchten.

Ab Winter 2019 soll dann die endgültige Version im Windows Store verfügbar sein und für jedermann Nutzbar.

Das .NET Framework ist tot, lang lebe .NET 5

Wie im letzten Jahr bereits angekündigt, wird ab 2019 das .NET Core Framework zum Hauptframework und das klassische .NET Framework, welches derzeit in der Version 4.8 vor liegt wird weitestgehend “eingefroren”.

Auf der Microsoft Entwickler Konferenz BUILD 2019 hat Microsoft nun die endgültige Strategie für das neue .NET Framework veröffentlicht und die sieht vor, dass das klassische .NET Framework so nicht weitergeführt wird.

D.h. alle, die derzeit immer noch damit arbeiten (und das dürfte nach wie vor die Mehrheit sein), sollten sich nun endgültig Gedanken machen, wie sie die Migration in den nächsten 2-3 Jahren durchführen, denn auch wenn das klassische .NET Framework noch einige Zeit funktionieren wird, wird es wohl nicht mehr mit neuen Funktionen ausgestattet. Ähnlich der /36er und /38er Umgebung auf der IBM i.

Und alle, die jetzt planen mit .NET ihre Anwendungen zu modernisieren, sollten auf jeden Fall auf .NET Core setzen und sich gar nicht erst mit dem klassischen .NET Framework beschäftigen, wie ich es seit einem Jahr immer wieder betont habe.

Gleichzeitig hat Microsoft auch neue Versionsnummern und einen Lebenszyklus für .NET bekannt gegeben.
So wird die finale Version von .NET Core 3.0 im September erscheinen und im November 2019 von einer Long Term Support (LTS) Version 3.1 abgelöst.

Danach soll jedes Jahr eine neue Version erscheinen, beginnend mit der Version .NET 5.0 (ohne Core!) im November 2020.
Alle 2 Jahre erscheinen dann LTS Versionen, die an den geraden Nummern zu erkennen sein sollen. D.h. im November 2021 mit Version 6.0 ist die nächste LTS Version geplant, gefolgt von Version 7.0 im November 2022 und der nächsten LTS Version 8.0 im November 2023.

Damit folgt Microsoft dem Schema, dem auch andere Frameworks und Plattformen mittlerweile folgen, allen voran Node.js.

Die permanente Weiterentwicklung und damit verbunden das Lernen der neuen Besonderheiten, ziehen somit immer weiter in die Welt der Softwareentwickler ein. Den Luxus, einmal etwas zu lernen und damit dann 5-10 Jahre (oder noch viel länger) produktiv zu arbeiten, können sich immer weniger leisten und die, die es tun, riskieren ihre Zukunft und im schlimmsten Fall die, des Unternehmens.

Die vollständige Übersicht finden Sie im Blogpost von Richard Lander, seineszeichens Program Manager des .NET Teams
https://devblogs.microsoft.com/dotnet/introducing-net-5/

Neue Webcast Serie – Transformer on i

Die digitale Transformation der Unternehmen ist in vollem Gange und wer jetzt nicht den Anschluss verlieren will, braucht eine gute Strategie und die richtigen Werkzeuge, das Know How und die Leute, um diese Strategie schnell und effektiv umzusetzen.

Meine Kollegen, Partner und ich unterstützen Sie dabei eine solche Strategie aufzustellen und umzusetzen.
Dabei spielt die technische Umsetzung zunächst eine untergeordnete Rolle. Oberste Priorität hat zunächst einmal das Ziel, welches man erreichen möchte. Darauf aufbauend und auf den vorhandenen Ressourcen, entwickeln wir gemeinsam mit Ihnen eine Strategie, um dieses Ziel schnellstmöglich zu erreichen.

Spielt die Plattform IBM i bei dieser Strategie eine Rolle, dann erfahren Sie in diesen 3 Webcasts, wie Sie schnell und effektiv

  1. Webservices und Microservices in ihre vorhandene Anwendungen integrieren bzw. die vorhandenen Anwendungen in Webservices oder Microservices umsetzen können. Dabei spielt es keine Rolle, ob Sie Anwendungen aus 1976 oder aus 2018 verwenden. Ob diese in RPG, Cobol, C++ oder Node.js geschrieben sind.
    Termin: 25. Juni 2019 – 10:00 Uhr bis 11:30 Uhr
  2. mit dem Domain Model Designer neue Web Anwendungen auf IBM i erstellen, ohne zu programmieren. Diese sind dennoch individuell anpassbar, wenn es gewünscht wird.
    Termin: 27. Juni 2019 – 14:00 Uhr bis 15:30 Uhr
  3. ihre 5250 Dialogprogramme in wenigen Minuten browserfähig bekommen und mit RPG oder Cobol erweitern können, ohne, dass Sie den original Quellcode anpassen müssen. Bei der Gelegenheit können Sie den Anwendungen auch ein “Facelifting” verpassen oder den Workflow verändern, wie Sie im Webcast sehen werden.
    Termin: 02. Juli 2019 – 14:00 Uhr bis 15:30 Uhr

Webservices und Microservices

  • Nutzen von Webservices und Microservices in eigenen Anwendungen
  • Bereitstellen von Webservices und Microservices auf Basis vorhandener (alter) Anwendungen
  • Programmierung in RPG, Cobol, C++, Node.js, etc.

Domain Model Designer

  • Web Anwendungen für IBM i ohne Programmierung
  • Dennoch voll individuell anpassbar
  • Dynamisches Erweitern von vorhandenen Datenbanktabellen

5250 2.0 - Green Screen Reloaded

  • Schneller 5250 Emulator im Browser
  • Erweiterung der vorhandenen Masken mit 5250 oder HTML5
  • Zahlreiche Steuerelemente und Workflowänderungen ohne den Code zu verändern

Sie haben Interesse an einem oder mehreren Webcasts?

Kein Problem – senden Sie mir einfach eine kurze Email und teilen Sie mir mit, an welchem Webcast Sie teilnehmen möchten oder klicken Sie auf den o.g. Button und registrieren Sie sich dort.
Sie erhalten dann die Zugangsdaten.

Sie sind Interessiert, haben aber an den o.g. Terminen keine Zeit?
Auch kein Problem. Teilen Sie mir mit, an welchem der Webcasts Sie interessiert sind und Sie erhalten nach dem Webcast einen Link zur Aufzeichnung und können sich den Webcast in Ruhe anschauen, wenn Sie Zeit haben.

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!

DAS RPG / ILE Web Framework für alle IBM i Entwickler – kostenlos!

Warum sind Programmierplattformen, wie Java, Microsoft .NET, NODE oder Angular 6 so erfolgreich und werden von Millionen von Software Entwicklern genutzt?

Frameworks

Klar – weil all diese Plattformen (von Programmiersprachen kann man bei den o.g. nicht mehr reden) über ein oder gar mehrere, mächtige Frameworks verfügen, die den Entwicklern das Leben leichter machen (sollen).
Diese Frameworks bieten massenweise Funktionen, die ein Entwickler ansonsten selbst erstellen muss.

Communities

Ein weiterer Grund, warum die o.g. Programmierplattformen so erfolgreich sind, ist schlichtweg die Zahl der Entwickler, die damit arbeiten und sich dabei in unterschiedlichen Bereichen engagieren.
Es gibt unzählige Beispielprojekte auf Open Source Basis, die auf den unterschiedlichsten Plattformen gehostet werden.
Allen Voran auf GitHub, welches gerade von Microsoft übernommen wird und mit mehr als 28.000.000 (Millionen) Entwicklern die größte Plattform darstellt.

Und IBM i?

Auf der IBM i oder früher AS/400, hat sich von Anfang an die Programmiersprache RPG und ein wenig Cobol durchgesetzt. RPG wurde von IBM seit den 50er (!!!) Jahren immer weiter entwickelt und ist aktuell mit der Ausprägung von Total Free RPG kaum wieder zu erkennen.
IBM hat uns mitte der 90er Jahre mit dem “Integrated Language Environment” (ILE) eine mächtige Weiterentwicklung der vorhandenen Programmiersprachen auf der IBM i beschert und damit die Weichen für modulare Programmierung gestellt, bei der es kein Problem ist verschiedene Programmiersprachen miteinander zu mischen.
Leider hat IBM bei all den Möglichkeiten, die sie mit ILE der Plattform geschenkt haben, vergessen ein ILE Framework mit zu liefern oder zumindest aufzubauen.
Genau aus dem Grund hat sich dann auch jedes Unternehmen und teilweise sogar in den Unternehmen noch einmal jeder Programmierer, seine eigene Funktionsbibliothek oder quasi ein Mini Framework aufgebaut. Ich weiß nicht, wie viele Varianten von Datumsfunktionen oder Textreplacements ich in den vergangenen 20 Jahren gesehen habe…
IBM hat in der Zwischenzeit angefangen, mehr oder weniger schnell und komfortabel, RPG mit neuen Funktionen, wie z.B. embedded SQL oder XML Anweisungen auszustatten, wobei diese Funktionen meist sehr spät und Anfangs auch nur sehr schwach bzw. umständlich kamen und immer noch kommen.
Ähnlich sieht es mit der Unterstützung von Web Programmierung und Web Service Programmierung aus, sowie der Unterstützung von JSON, die auch jetzt erst nach und nach Einzug in die IBM i Welt durch IBM findet.
Wollte und will man hier wirklich aktuelle Anforderungen abdecken, so wird das mit RPG / IBM Bordmitteln teilweise recht schwierig oder gar unmöglich und wenn es denn klappt, ist es nicht immer die schnellste Lösung, wobei vor allem Web Services von der Geschwindigkeit leben…
Das ist einer der Gründe, warum IBM i von vielen immer noch als veraltetes und “unmodernes” System gesehen wird, da die vorhandenen Programmierer, die meist in RPG oder Cobol denken, von IBM hier nicht so unterstützt wurden, wie dies z.B. bei Java der Fall ist.
Die Strategie von IBM Ende der 90er Jahre war ja auch klar, dass man alle RPG / Cobol Programmierer zu Java bewegen wollte. Doch das hat aus verschiedenen Gründen nicht funktioniert.
Oft blieb und bleibt dann keine Alternative, als dann doch einen anderen Lösungsweg in Form von .NET, Java, Node (.js), Python oder PHP zu beschreiten, was für den “normalen” RPG / Cobol Entwickler nicht immer leicht, wenn überhaupt möglich war bzw. ist, da das Tagesgeschäft viele komplett in Anspruch nimmt und sich diese Situation in den letzten Jahren eher noch verschärft hat.

Commmunity Edition

Genau deshalb hat sich auf diese Themen vor ca. 11 Jahren schon jemand außerhalb von IBM gestürzt und einen Weg geschaffen, mit dem auch “normale” RPG und Cobol Entwickler schnelle Web Anwendungen und Web Services in kurzer Zeit mit vorhandenem Know How entwickeln können.
Sogar schneller, als mit den bisher bekannten Mitteln, denn die Lösung basiert auf einem nativen IBM i Application Server, den es so nicht noch einmal gibt.

IceBreak heißt die Lösung, die komplett auf ILE basiert und dem Entwickler bereits in der kostenlosen Community Edition unzählige Funktionen in Form eines ILE Frameworks an die Hand gibt, mit der er innerhalb seiner RPG oder Cobol Programme kinderleicht mit XML, JSON, IFS, sowie Web Anwendungen arbeiten kann und das in einer unglaublichen Geschwindigkeit.
IceBreak ist deshalb so schnell, weil es selbst in ILE Programmiert ist und somit nicht, wie die anderen Lösungen auf IBM i, wie der Apache Server, Websphere, Lotus Domino oder auch Node, innerhalb der PASE Umgebung läuft, sondern richtig nativ und damit die volle Geschwindigkeit des Systems nutzen kann.
Dabei unterstützt IceBreak jede beliebige Programmierweise. Vom klassischen Spalten RPG, bis zum modernsten Total Free oder Cobol, C, C++ in all seinen Facetten. Alles, was die IBM Compiler umwandeln können, wird auch von IceBreak unterstützt, denn es erzeugt native IBM i ILE Objekte, basierend auf den IBM Compilern!
Die Community Edition von IceBreak steht dabei jedem dauerhaft kostenfrei zur Verfügung. 
Was damit nicht geht, sehen Sie in der Übersicht:

Eine Übersicht der Funktionen von IceBreak, sowie der Unterschiede der einzelnen Editionen, finden Sie hier

Email: mal@mlitters.com

oder rufen Sie mich einfach an.

Drum prüfe, wer sich ewig bindet – Modernisierung in die Sackgasse

Anwendungsentwicklung, als auch deren Modernisierung ist ein kontinuierlicher Prozess, der niemals endet und permanent gelebt werden muss. 
Er fängt nicht bei der Datenbank an und endet im Frontend, sondern umfasst das gesamte Spektrum einer Anwendung, sowie deren gesamtem Lebenszyklus.

Viele Unternehmen, die IBM i mit klassischen RPG und/oder Cobol Programmen einsetzen, starten oft mit der Oberflächenmodernisierung, da dies jeder Anwender – und vor allem Entscheider – als erstes sieht.Idealerweise sollte dies die letzte Komponente sein, die man modernisiert, will man langfristig eine wartbare, flexible und offene Anwendung erhalten, die die Herausforderungen der Gegenwart und Zukunft optimal erfüllt.

Aber wann haben wir schon ideale Zustände…

Ich bin jetzt seit über 20 Jahren im Bereich Anwendungsmodernisierung auf den unterschiedlichsten Ebenen, mit den unterschiedlichsten Voraussetzungen und unterschiedlichsten Plattformen aktiv und kann daher aus Erfahrung berichten, dass es unglaublich wichtig ist, sich vor dem Beginn lieber 5 mal zu viel Gedanken zu machen, als einmal zu wenig, denn der Pfad, den wir für die Modernisierung einschlagen, kann irgendwann für das Überleben des Unternehmens entscheidend sein.

Deshalb auch die Überschrift, die so aber auch nicht ganz korrekt ist, denn „ewig“ besteht nichts (außer vielleicht die AS/400). Korrekt wäre daher „Drum prüfe, wer sich lange bindet“, denn vorweg muss ich jeden mit der bitteren Realität vertraut machen, dass sich jede moderne Technologie in einem stetigen Wandel befindet und was vor 5 Jahren noch modern war, ist heute „Old school“. Dabei spielt es keine Rolle mehr, ob man Desktop, mobile oder Web Oberflächen entwickelt. Alle Frameworks, Tools und Programmiersprachen entwickeln sich permanent weiter und das in einem mittlerweile unglaublichen Tempo.

Umso wichtiger ist es, dass man sich bei der Modernisierungsstrategie für Technologien, Tools und Frameworks entscheidet, die nicht nur jetzt auf dem aktuellen Stand der Technik sind, sondern auch gute Chancen haben, für einen längeren Zeitraum dort zu bleiben.
Wobei in der heutigen Zeit mit längerem Zeitraum i.d.R. von ca. 5 bis max. 10 Jahren gesprochen wird. Alles andere wäre unseriös. Die sog. LTS (Long Term Support) Zyklen der verschiedenen Frameworks und Entwicklungsmöglichkeiten sind teilweise wesentlich kürzer und umfassen meist nur 1-2 Jahre, bis man auf eine neuere Version wechseln muss, will man weiterhin support dafür erhalten und den braucht man im geschäftlichen Umfeld, denn allein das Thema Sicherheit erfordert das.

Aus dem Grund führe ich mit meinen Kunden i.d.R. eine gründliche Analyse durch, was aktuell im Unternehmen an Anwendungen, Tools, Plattformen, Datenbanken, aber auch Entwickler Know How und künftigen Entwicklern vorhanden und geplant ist.
Immer mehr Firmen setzen z.B. Cloud basierte Lösungen ein und sei dies „nur“ in einzelnen Fachabteilungen, weil man dort „mal schnell“ eine Lösung für ein bestimmtes Thema gebraucht hat, was man nicht selbst entwickeln kann. Auch solche Themen müssen entsprechend berücksichtigt werden und die Strategie sollte offen für diese Entwicklungen sein, selbst wenn man bisher noch nicht davon betroffen war.

Leider (oder Gott sei Dank – je nach Blickwinkel) komme ich immer wieder zu Firmen, die sich irgendwann für eine Richtung der Modernisierung entschieden haben und sich dabei entweder nicht richtig oder von den falschen Leuten haben beraten lassen und nun in einer Sackgasse gelandet sind, aus der sie irgendwie wieder heraus müssen.

Sei dies der Pfad zu Visual Basic 6 (VB6) oder Visual Age for RPG in der Vergangenheit. Auch hier war irgendwann recht klar, dass diese Technologien keine langfristige Zukunft mehr haben werden und dennoch haben noch Anfang der 2000er Firmen begonnen damit zu „modernisieren“.


Zu Ihrer Beruhigung – das betrifft nicht nur Unternehmen, die IBM i einsetzen und deren Anwendungen modernisieren. Das betrifft alle!

Vor ein paar Monaten kam ich z.B. zu einem Unternehmen, welches vor knapp 3 Jahren angefangen hat seine alten VB6 Programme in Richtung Visual Basic .NET auf Basis von Windows Forms zu modernisieren.
Nachdem man auf dieser Basis bereits mehr als 60 Programme modernisiert hatte, stellte man fest, dass diese Oberflächentechnologie weder Responsive ist noch sich in irgendeiner Form (zumindest nicht mit vertretbarem und vernünftigen Aufwand) auf mobile Geräte, wie Smartphones oder Tablets oder gar in den Browser übertragen lässt.
Das man für jedes halbwegs moderne Feature sowieso schon kostenpflichtige Fremdkomponenten verwenden musste, hatte man zu der Zeit bereits zähneknirschend akzeptiert. 
Ein „toller“ .NET Trainer, hatte das Unternehmen dahingehend beraten und einige Projekte und Schulungen mit dem Kunden durchgeführt.
Dumm nur, dass dieser „tolle“ Trainer scheinbar nur ein cleverer Verkäufer war, der es versäumt hat seine eigenen Kenntnisse in den letzten 12 Jahren aufzufrischen, denn die Windows Forms Technologie wurde bereits vor Jahren von Microsoft in den sog. Maintenance Mode versetzt, was bedeutet, sie wird lediglich am Leben erhalten aber schon lange nicht mehr weiterentwickelt.
WinForms wurde bereits 2006 durch die Windows Presentation Foundation (WPF) und diese später durch das Modern UI auf Basis der Universal Windows Plattform ersetzt.
Da dieser Trainer jedoch keine „Lust“ hatte, seine eigenen Kenntnisse dahingehend zu erweitern und bisher immer wieder Kunden gefunden hat, die seinen Ratschlägen folgen, empfiehlt er natürlich auch heute noch diesen Weg, denn WinForms funktioniert doch einwandfrei unter Windows 10…. (übrigens läuft RPG II auch noch unter IBM i 7.3!!!).

Das man damit aber keine vernünftige Trennung der View vom Code realisieren, keine plattformübergreifenden Anwendungen entwickeln kann, die sich an die jeweilige Displaygröße anpassen und bei jeder Kleinigkeit, die man einigermaßen „modern“ umsetzen möchte, auf kostenpflichtige Fremdkomponenten angewiesen ist, hat er mal eben vergessen zu erwähnen – evtl. weiß er das selbst noch nicht einmal.
Von den technischen „Feinheiten“ wie den Einsatz von modernen Programmiermustern wie Model View ViewModel, Testdriven Development, etc. einmal ganz zu schweigen. 
Jetzt muss der IT Leiter seinem Vorstand erklären, warum das Modernisierungsprojekt, welches eigentlich im vollen Gange sein sollte, bereits wieder migriert werden muss – zumindest in Teilen. Zunächst müssen ca. 5 Anwendungen umgestellt werden, die dringend auch auf mobilen Geräten laufen sollen. Der Rest folgt dann irgendwann.

Hochgeploppt ist die ganze Geschichte, weil man einen neuen Entwickler eingestellt hat, der sich mit dem .NET Framework in seiner aktuellen Form gut auskennt und die ganze Geschichte mit einem „Ach Du Sch…..“ kommentiert hat, was beinahe zu seiner Entlassung geführt hätte…. Nur so nebenbei.

Schade, dass dieser Kunde mich vor 3 Jahren nicht parallel angesprochen hat, denn wir standen zu der Zeit bereits in Kontakt. Da aber einer der Entwickler den „tollen“ Trainer kannte, schaute man sich bei einer so wichtigen und richtungsweisenden Entscheidung für das gesamte Unternehmen, nicht weiter um oder holte sich mal eine 2te Meinung ein….

Dies zeigt aber sehr deutlich ein weiteres Problem vieler Unternehmen auf:
Die Geschäftsleitung kümmert sich um die IT Strategie selten so, wie sie es 2018 muss.

Baut ein Unternehmen z.B. eine neue Lager- oder Fabrikationshalle, dann wird die Geschäftsleitung meist bis in die Details eingebunden und es werden zig verschiedene Experten ins Haus geholt, um die optimale Planung und Umsetzung zu realisieren, denn dabei handelt es sich schließlich um eine strategische Investition für das Unternehmen.

Was bitte ist eine Modernisierungsstrategie der Anwendungen?

Schauen Sie sich die Probleme an, die Haribo derzeit mit der Auslieferung seiner Waren hat. Durch die Umstellung auf SAP wird Haribo dieses Jahr wahrscheinlich 25% weniger Umsatz erzielen.
https://www.wiwo.de/unternehmen/it/haribo-lidl-deutsche-post-und-co-die-lange-liste-schwieriger-und-gefloppter-sap-projekte/23771296.html

So etwas kann andere Firmen die Existenz kosten und hat es auch schon, wie ich selbst erleben musste.

Genauso kann die Modernisierung in die falsche Richtung zu erheblichen Problemen führen – vor allem in einer Zeit, in der die Anforderungen stetig zunehmen und immer schneller umgesetzt werden müssen.
In der Unternehmen immer schneller und flexibler auf die Wünsche ihrer Kunden eingehen müssen.
Hierzu bedarf es Softwareentwickler, die mit aktuellen Technologien, Tools und Kenntnissen effektiv diese Herausforderungen meistern.

Deshalb empfehle ich jedem sich rechtzeitig zu informieren und nach Möglichkeit mit Beratern zu sprechen, die einen Überblick über die verschiedenen Möglichkeiten haben und nicht nur einen Weg kennen und diesen logischerweise dann auch empfehlen.

Sie sind an einer Zusammenarbeit, Schulung 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.

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.