Die Top 3 Vorurteile gegen EGL

[Elke Plato]

Vorurteile sind unverzichtbar. Schließlich können wir nicht ständig alles von allen Seiten betrachten. Manchmal genügen Bauchgefühle, erste Eindrücke und das, was die anderen sagen.
Doch je folgenreicher die Entscheidung, desto lohnender ist es, die Türen im Kopf wieder zu öffnen. IT-Entscheidungen haben immer große Konsequenzen.
Hier finden Sie zum Thema EGL neue Sichtweisen und Impulse für kritische Gespräche.
Ich wünsche Ihnen die beste Entscheidung.

Vorurteil 1: EGL bietet keinen Investitionsschutz

Das stimmt – wenn man Software an der Ewigkeit misst. Wem es aber um die absehbare Zukunft geht: IBM hat EGL vor allem deshalb entwickelt, um bestehende Investitionen noch lange nutzen zu können. Wenn das Alte noch taugt, neue Ufer aber nicht mehr erreichbar sind, dann kann eine gute Brücke beides verbinden und Neues schaffen. EGL ist diese Brücke.
Wer sie nutzt, schont seine Ressourcen, denn:
Ihre bestehenden Assets lassen sich integrieren.

Ihre RPG- und COBOL-Entwickler lernen leicht und schnell, mit EGL umzugehen.
Ihrer Entwicklungsmannschaft erschließen sich neue Möglichkeiten, aber deren Knowhow über Business-Prozesse schafft weiterhin Wert.
Kennen Sie einen besseren Weg, um bestehende IT-Investitionen zukunftstauglich zu machen?

Vorurteil 2: EGL ist proprietär

Was sind die obersten Prioritäten bei Business-Anwendungen? Wir denken, es sind:
•Stabilität
•Sicherheit
•und eine einfache, effektive Handhabung.

Stößt hier der reine Open-Source-Ansatz nicht an seine Grenzen? Braucht es hier nicht jemand, der verlässlich filtert, wartet, vereinfacht? Java ist nur auf den ersten Blick nicht-proprietär. Man ist abhängig von diversen Open-Source-Frameworks, die sich ständig verändern und teilweise nicht zueinander passen. Mit den Problemen, die daraus entstehen, steht man dann alleine da. Was also ist besser: Lauter volatile Abhängigkeiten oder eine Bindung an IBM, die die Verantwortung übernimmt?

Vorurteil 3: EGL hat keine Entwickler

EGL ist so einfach, dass jeder schnell ein Entwickler wird. RPG und COBOL Entwickler brauchen gerade mal vier Wochen Schulung, um EGL zu beherrschen. Ähnlich ergeht es allen anderen Business-Entwicklern, seien es Fans von Natural, CSP, VAGen oder ähnlichen Anwendungen.
Java-Entwickler haben sowieso kaum Probleme mit der Umstellung, denn die EGL-Syntax lehnt sich an die Java-Syntax an. Zugegeben: Java-Puristen mögen beim Gedanken an EGL erschaudern. Aber wer tagtäglich fachliche Probleme lösen will und nicht Java-Probleme, der wird EGL als Hilfe zu schätzen lernen.
Außerdem bringt EGL zwei Entwicklergenerationen zusammen: Es wirkt wie ein Dolmetscher zwischen den traditionellen Gemeinde und der jüngeren Java-Gemeinde. Das erleichtert nicht nur den Generationenwechsel im Unternehmen – es macht ihn produktiv.

Fazit

Mittlerweile haben so viele Unternehmen die Modernisierung auf Basis von EGL gewagt. Denn sanfter als mit EGL geht’s nicht: Für jede Betriebsanforderung finden sich die passenden kleinen Schritte – ob vertikal in Form von Geschäftskomponenten oder horizontal in Form von technischen Schichten. So ermöglicht die horizontale Migration bereits zu Anfang eine einheitliche, moderne Benutzeroberfläche – und er-füllt so den Hauptwunsch vieler Kunden innerhalb kürzester Zeit. EGL ist ein Meister der Integration. So bleibt alles sicher erhalten. Parallelbetrieb ist möglich. Das Neue kommt schrittweise und erst dann, wenn es die Anforderungen perfekt erfüllt.

[BenderD]

... dann will ich die Gelegenheit mal nutzen, fürs kritische Gespräch.

... wenn man EGL alles nachsagen darf, eins nicht: Kurzlebigkeit - es hält sich lange und zäh. EGL ist nämlich keineswegs neu, sondern so ca. 30 Jahre alt und ist das Pendant zu SYNON in der Mainframe Welt, sozusagen das SYNON für Besserverdienende. Wenn man heute so tut, als sei das was völlig Neues und sich mittlerweile sogar der Historie schämt, warum sonst verschwinden die Seiten, die auf die Historie hindeuten stikum von den IBM Webseiten, verbessert das nicht die Glaubwürdigkeit.
Was an EGL neu ist, ist in erster Linie die Zielgruppe, nachdem EGL in der Mainframe Community dasselbe Schicksal ereilte wie SYNON in der AS/400 Community (woran das wohl liegen mag - beides?), lässt man es jetzt auf die AS/400 Klientel los, getreu dem Motto: die sind so blau ausgerichtet, die nehmen alles. Ganz ohne Berechtigung ist diese Denke ja nicht, die haben ja auch den LPEX gefressen, diesen angestaubten Mainframe Editor, der mit WDSC fröhliche Urstände feierte und die treuesten Notes Anwender haben auch eine AS/400 im RZ stehen und außerdem haben die ja nix Besseres und kenne oft auch nichts Besseres.

Nun gut, Schwamm drüber, was ist EGL heute und wie steht es im Vergleich zu C# und Java da:

Im Sprachumfang und in der Sprachdefinition unterscheiden sich diese drei nicht sehr wesentlich, schließlich sind die alle von Java abgeschrieben, an manchen Stellen gut (man kann dabei durchaus auch Fehler rausmachen), an anderer Stelle schlecht (man kann dabei durchaus Fehler reinmachen), das kennt man ja noch von der Schule, und Java ist auch nicht wirklich ein Original.

C# ist für die .NET Welt sicherlich ohne Alternative, wenn man mal von VB dem C# für Arme und Kranke absieht, der minimal größere Lernaufwand für C# wird vom Compiler mit deutlich mehr Arbeit belohnt, die er dem Programmierer abnimmt.
Java ist das Tor zur OpenSource, die mittlerweile an vielen Fronten kommerzielle Software überrundet hat (Tomcat, Eclipse, Apache WebServer), es gibt für (fast) alles und jedes Komponenten höchster Qualität und der Standardisierungsprozess solcher Komponenten schreitet mit Atem beraubenden Tempo voran.

EGL schwächelt genau an dieser Ecke, es fehlt an Komponenten an jeder Ecke und an jedem Ende.

Die in den Raum gestellte Behauptung des geringen Lernaufwandes (wenn das denn überhaupt stimmt), wird bei weitem über kompensiert an den nicht zu übersehenden Defiziten an Lernangeboten und an dem noch größeren Defizit an ausgebildeten Programmierern und Ausbildern. Das hat man bei RPG schon behauptet, dass das jeder Frisör kann, nur sehen dann manche Programme so aus wie Frisuren, die von einem Programmierer gemacht worden sind.

D*B

Hier finden Sie zum Thema EGL neue Sichtweisen und Impulse für kritische Gespräche.

[B.Hauser]

Eine weitere Meinung zum Thema EGL und den Vorurteilen.

Ich muss Dieter zustimmen, zumindest, was die "Langlebigkeit" von EGL angeht und wie IBM die AS/400, iSeries, System i (oder wie auch immer) Gemeinde mit EGL zu verschaukeln versucht hat.

Dass EGL nicht native für das System i entwickelt wurde, merkt man schon allein daran, dass EGL nur JAVA oder COBOL Code generiert, aber kein RPG, die Haupt-Programmiersprache auf i. EGL wurde erst auf die i gebracht, als der Ruf nach einer einfachen Entwicklungsmethode für graphische Oberflächen auf der i laut wurde, als Java trotz massiver Bewerbung nicht so angenommen wurde wie geplant ... und als sich immer mehr Nutzer von EGL in der Mainfraime-Welt nach Alternativen zu EGL umgesehen haben.

M.E. ist EGL genauso ein halbherziger Versuch die i Gemeinde zu besänftigen wie die anderen Tools, wie z.B. VARPG, das seit mehreren Releasen nicht mehr erweitert wurde oder Webfacing, an dem aktuell in Toronto kein Mensch mehr entwickelt oder HATS, die IBM zwischenzeitlich ins Rennen schickte.

Wenn EGL von IBM als das "neue" Parade-Pferd zur Entwicklung von Anwendungen mit graphischer Oberfläche auf der i ist, warum engagiert sich IBM nicht mehr dafür?
(OK, man kann sich auch fragen, warum macht IBM nicht mehr für die i und lässt sie komplett in der p-Power aufgehen).

... alle 2 Jahre gibt es einen Hype von Artikeln über EGL und dann ist wieder für 2 Jahre (oder für immer) Funkstille. EGL-Foren im Internet gibt es wenige mit noch weniger aktiver Beteiligung.

Warum habe ich bislang von allen, die ich gefragt habe, wie EGL angenommen wird und sich durchsetzt nur ausweichende Antworten bekommen?
Unter denen die ich gefragt habe waren u.a. auch Todd Britton (Chef von Rational) und Claus Weiss (verantwortlich für EGL in Toronto) und auch Mitarbeiter von PKS.

Warum waren z.B. in diesem Jahr auf der Common Conference in Orlando/USA von über 350 Vorträgen und Präsentationen noch nicht einmal eine handvoll über EGL ?
Allein über RPG OA gab es mehr Präsentationen und Informationen als über das komplette EGL.

Stößt hier der reine Open-Source-Ansatz nicht an seine Grenzen? Braucht es hier nicht jemand, der verlässlich filtert, wartet, vereinfacht? Java ist nur auf den ersten Blick nicht-proprietär. Man ist abhängig von diversen Open-Source-Frameworks, die sich ständig verändern und teilweise nicht zueinander passen. Mit den Problemen, die daraus entstehen, steht man dann alleine da. Was also ist besser: Lauter volatile Abhängigkeiten oder eine Bindung an IBM, die die Verantwortung übernimmt?

Habe ich hier irgendwas falsch verstanden oder wird hier gesagt, dass man EGL einer Open Source Lösung vorziehen sollte?

... aber EGL wird Open Source, zumindest ist dies geplant:

• EGL Goes Open Source - System iNetwork - September 2010
• EGL Development Tools Project - Eclipse.org
• Open Source EGL Means an RPG Generator Is Possible - The Four Hundred - Juni 2010

... damit ist das eingetreten, was ich schon lange insgeheim befürchtet habe, IBM will EGL abstoßen!
(Warum? ist Spekulation!)

M.E. ist EGL viel zu proprietär (nur auf IBM Maschinen) und zu alt, als dass sich hier eine große Open Source Gemeinde entwickeln könnte, die das Produkt weiterbringt. Sollte es eine Weiterentwicklung geben, dann nur für den Bereich Java (und warum sollten sich Java-Programmierer dies antun?), aber nicht für Cobol ... und RPG kann man gleich abschreiben (wer kennt schon RPG, hinter dem sich nicht Role Plaing Game versteckt?).

... und sollte man darauf wirklich die Zukunft seiner Software bauen?

[THatje]

Es ist schon sehr interessant wie kontrovers doch die Positionen zu EGL sind. Ich empfehle jedem sich sein eigenes Bild zu machen. Die Historie von EGL findet man zum Beispiel hier : https://www.ibm.com/developerworks/m...ory%20of%20EGL

Ich kann da nirgendwo Geheimniskrämerei seitens der IBM entdecken.

Und zur eingenverantwortlichen Meinungsbildung gehört auch ausprobieren. Versuchen Sie sich mal an EGL. Meine Meinung : Es lohnt sich.

Meine ersten Begegnungen mit EGL waren ohne jegliche historische Vorbelastungen. Vielleicht hat diese unvoreingenommene Sicht auf die Dinge dabei geholfen, dass ich heute von EGL sehr positiv angetan bin.

Mich fasziniert die Unabhängigkeit von den komplexen technischen Details. Ich habe keine Ahnung von javascript, aber ich kann plötzlich einen RUI-Screen bauen.
Einen Webservice erstellen und nutzten. Fast kinderleicht.
Bestehende Programme auf dem System I aufrufen. Gar nicht so schwer. Integration von Dataqueues und Dataareas ist auch kein Hexenwerk.

Deployment Richtung System I oder Windows oder.... WAS oder Tomcat oder ...... Das ist echt proprietär und voll auf IBM und Sytem I fokussiert ;-)

Und ich bin der Meinung, dass die Menschen, die mit RPG ihr Geld verdienen keine Angst vor EGL haben müssen. EGL ist eher eine Bereicherung.

Ob man der IBM vertraut, dass EGL zukunftssicher ist, muss jeder mit sich selbst abmachen. Ich habe da eher eine positive Sichtweise der Dinge.

Der Lernaufwand wird etwas zu niedrig angesetzt. Ja, man ist relativ schnell mit Sprachkonstrukten von EGL vertraut und auch der Umgang mit der IDE lässt sich schnell lernen. Aber wenn dann die Tutorials verlässt und "echte" Anwendungen bauen will, wird es schon komplizierter und komplexer.

Also ohne Vorurteile informieren, anschauen und ausprobieren ist das, was ich jedem empfehlen möchte.

Thomas Hatje

[tsh1970]

Achtung Polemik:

Stimmt genau diese 3 Vorurteile habe ich.

Ich verfolge EGL nun schon eine Weile, und mir stellt sich wirklich die Frage,
wer braucht es und für was?

Für eine zeitgemässe Oberfläche und Funktionen? Es gibt doch zwischenzeitlich genug Möglichkeiten um die iSeries mit einer ordentlichen GUI zu versehen.

Mit Open Access wurde meiner Meinung nach ein wichtigerer Schritt zur Öffnung für neue Oberflächen realisiert als mit EGL. Anbieter für OA-Handler und einige wirklich gute Lösungsansätze gibt es bereits auf dem Markt.
(Übrigens auch PKS , macht man sich da nicht selber Konkurrenz? )

Ich programmiere seit 20 Jahren RPG und ca. 7 Jahre C# und Java, da brauche ich persönlich nicht noch EGL.

Nun es ist schon schwierig genug RPG Programmierer zu bekommen die jünger als 40 sind,
soll man denen dann auch noch EGL zumuten? Sieht so dann Investionsschutz aus?

Oder soll man das Frontend nicht lieber durch einen jungen Fachmann auf .NET, Java oder sonst was entwickeln lassen, die wesentlich besser auf dem freien Markt vertreten sind als RPG- oder gar EGL-Spezialisten.

EGL ist doch ehrlich gesagt nur eine Krücke zwischen zwei Welten.
Langfristig bietet nur eine Migration der Oberflächen auf heutige, gängige Standards und beibehalten der Geschäftslogik und Datenbank auf der iSeries einen wirklichen Investionsschutz.

Ich persönlich gebe EGL keine große Überlebenschance, aber wie uns die IBM schon mehrfach gezeigt hat, leben Totgesagte länger.

Thorsten

[THatje]

Achtung Polemik...

Wenn man keine Ahnung hat ......


Zitat:
"Langfristig bietet nur eine Migration der Oberflächen auf heutige, gängige Standards und beibehalten der Geschäftslogik und Datenbank auf der iSeries einen wirklichen Investionsschutz."

RUI ist kein heute gängiger Standard ?
OA ist doch eher die Sackgasse.

Gerade mit dem RBD sind wir doch in der Lage modernste Applikationen zu erstellen. Gerade EGL hat die Stärke auf einfache Art und Weise bestehende Programme einbinden zu können.

[Fuerchau]

Auch die älteren Fachleute jenseits der 40 können schon .NET, Java usw. und beherrschen dann auch noch zusätzlich RPG.
Das sucht man dann bei den jüngeren Fachleuten eher vergeblich .

[tsh1970]

@Fuerchau, betrifft mich ebenso und sollte auf gar keinen Fall Kritik oder Abwertung von uns Älteren sein.

Aber rein Firmenpolitisch gesehen, schau mal was wir für Gehaltsvorstellungen haben und was ein fähiger Java oder C# Programmierer auf dem Markt kostet.

@THatje, auf die Ahnung gehe ich jetzt gar nicht erst ein Ist ein Rich User Interface jetzt neuerdings eine EGL Erfindung?

Aber sei mir nicht böse aber all deine Phrasen (nicht Argumente) hören sich so an als seien sie 1:1 aus einem Werbeprospekt für EGL entnommen.

Nachtrag: So für genug Wallung an einem Freitagnachmittag gesorgt,
aber abschliessend noch eine Frage:
Was wird wohl als erstes wieder vom Markt verschwinden EGL, .NET oder Java?

[Fuerchau]

Ich würde da auch auf EGL verzichten.
Auch RPG-Anwendungen kapseln sehr häufig Geschäftslogik in Unterprogramme mit definierten Schnittstellen.
Da schaffe ich mir halt eine entsprechende Anzahl externer SQL-Funktionen und Prozeduren und kann ebenso große Teile der alten Anwendung aus RPG dann per SQL nutzen und mich mit modernen Lösungen um die Frontends kümmern.

Aber was soll die Streiterei, es gibt inzwischen viele Lösungen das Know-How von RPG-Programmierern mit modernen Oberflächen zu nutzen, sei es .NET, Java, PHP u.v.m.

Wer EGL haben will soll es doch ruhig nutzen.

[THatje]

Am besten wir schalten mal die "Polemik" aus und begeben uns auf die sachliche Ebene.

Und dort hat jenseits aller Vorurteile alles seine Daseinsberechtigung.
RPG-OA mag in bestimmten Szenarien eine vernünftige Lösung sein. Wenn ich mit dem was ich damit erreichen kann zufrieden bin, warum nicht. Was mir dabei nicht gefällt ist die Begrenzung in der Funkionalität und die Abhängigkeit von Drittanbietern. Es sei denn ich kann meine eigenen Handler schreiben.

Ich kann auch GUI mit PHP, Java etc. bauen. Man erreicht sein Ziel damit auch garantiert.

Und dann gibt es eben auch dies EGL oder RationalBusinessDeveloper. Wir haben uns intensiv mit dem Tool auseinandergesetzt. Und können uns jetzt mit fundiertem Wissen darüber austauschen. Und dabei stößt man dann immer wieder auf platte Vorurteile, die sich jenseits jeglicher Realität bewegen.
Und wenn es sich wie Zitate aus dem Werbeprospekt anhört, kann ich es aus Überzeugung immer wiederholen.
Ich finde EGL und den RBD richtig gut. Mir gefällt es eben, dass ich mit EGL ohne Javascript-Kenntnisse RUI-Screens bauen kann. Mir gefällt diese Abstraktion von den totalen technischen Details. Mir gefällt die Unterstützung in allen Architekturebenen, die der RBD mir bietet.
Mir gefällt es, wie einfach die Integration und Nutzung von As400-objekten zu lösen ist. Egal ob Programmaufruf oder Nutzung z.B. einer Dataqueue.
Es gibt auch Momente, da könnte man die Software an die Wand klatschen. Und zwar immer dann wenn man mit Bugs kämpfen muss die tief in dem Tool vergraben sind. Aber auch das ist mit den letzten Versionen viel besser geworden.

EGL und der RBD sind nicht das Allheilmittel in dem vielschichtigen Thema Modernisierung, aber allemal Wert sich vorurteilsfrei damit auseinanderzusetzen. Was ich schlimm finde ist dieses Dreschen von platten Phrasen ohne wirkliches Detailwissen.

Just my 2 cents

[tsh1970]

Klar führen viele Wege zum Ziel und jeder wählt für sich den geeignesten. Ist ja durchaus legitim.

Ich möchte EGL auch auf keinen Fall abwerten. Was mich nur verstimmt ist die Darstellung von EGL als eierlegende Wollmilchsau.


Das schreiben von eigenen Handlern ist übrigens "relativ" einfach, gute Beispiele z.B. von Jon Paris, Susan Gantner gibt es aber auch bereits im Netz zu finden.

Der Nachteil an ROA ist sicherlich das es (noch) als kostenpflichtige Erweiterung angeboten wird und daher weniger Verbreitung findet wie wünschenswert wäre.

[Spateneder]

Ist das jetzt hier ein Reklame- und Plauderforum, oder was?