guisierung des green screen

[mk]

Hallo,

wir setzen seit einiger Zeit ProfoundUI ein. Die bieten 2 Produkte. Das Produkt Genie interpretiert den normalen 5250-Datenstrom und zeigt die Green-Screen-Masken im Browser an. Das allein bringt für uns noch keinen großen Vorteil. Aber es gibt zusätzlich den ProfoundUI-Designer, mit dem wir neue Bildschirme grafisch entwickeln können (Alles weiterhin in RPGLE). Da sind dann so ziemlich alle Komponenten, die man aus PC-Entwicklungsumgebungen kennt, drin (Comboboxen, Buttons, Checkboxen, Grids, Panels usw.). Wenn man beide Produkte zusammen einsetzt, bekommt man damit sofort eine vollständig browserbasierte Oberfläche, in der man nach und nach die Masken grafisch neu designen kann. Also eine sehr "sanfte" Migration.

Gruß,
Dieter

genau das ist das Problem..............................

Wir müssen diese Altlasten endlich mal loswerden
und uns mit den Tools nicht noch mehr Altlasten aufhalsen.

[nico1964]

genau das ist das Problem..............................

Wir müssen diese Altlasten endlich mal loswerden
und uns mit den Tools nicht noch mehr Altlasten aufhalsen.

Hallo,
das Problem mit neuem ist bei uns eigentlich ein anderes. In dieser Cobol-Anwendung steckt unheimlich viel Buisness-Logik, die die Prozesse unserer Anwender unterstützt und diese Logik wollen und können wir nicht aufbrechen. Beim Können scheitert es sowohl an zeitlichen als auch fachlichen Resourcen-.
Gruß
Andreas

p.s. ich möchte einfach eine "einfache" Lösung für die Ablöse unserer GreenScreen-Umgebung.

[mk]

Hallo,

In dieser Cobol-Anwendung steckt unheimlich viel Buisness-Logik, die die Prozesse unserer Anwender unterstützt und diese Logik wollen und können wir nicht aufbrechen. 

Das sagen alle..... Selbstverständlich sind unsere Programme
über die Jahre gewachsen, angepasst und laufen stabil.
Trotzdem kommt die Zeit für eine andere Umgebung.
Das heißt nicht das im Backend die alten Programme
nicht weiterlaufen sollen.

Aber was in Richtung RIA Entwicklung geht
sollte nicht mit den Sprachen RPG oder Cobol realisiert werden.

Nur als Beispiel:
Für eine Web Gridanzeige brauche ich auf dem System i
in PHP nur drei Zeilen Code.

[nico1964]

Hallo,
verstehe Deine Argumente, aber was ist mit den komplexen Prüfungen, die bei unseren GreenScreens ablaufen und mit von verschiedenen Eingaben abhängigen Aufrufen weiterer Screens, was wir bei uns durch den das Verwenden von mehereren Formaten innerhalb eines Dialogprogramms realisiert haben. Diese Prüfungen will keiner Aufbrechen, da bereits bei unseren Anwendern das nötige KnowHow fehlt um zu definieren, wie die Abläufe zusammenhängen.

[dschroeder]

Hallo nico1964,

wir setzen bei uns kein Cobol ein. Deshalb weiß ich nicht, ob Profound für Cobol geeignet ist. Ich glaube es aber nicht, weil der Designer die RPG-Open Access Schnittstelle benutzt. Ich weiß nicht, ob es so etwas auch für Cobol gibt. Genie (der Screenscraper) geht natürlich für alle 5250-Masken und damit auch für Cobol. Aus meiner Sicht ist das aber nicht die Lösung. Ohne den Designer macht das keinen richtigen "Spaß".

[RobertMack]

p.s. ich möchte einfach eine "einfache" Lösung für die Ablöse unserer GreenScreen-Umgebung.

Vielleicht findes Du etwas Zeit, dieses PDF mit dem Suchbegriff "COBOL" durchzugehen: IceBreak Programmers Guide

Gruß,
Robert

[mk]

Hallo,
verstehe Deine Argumente, aber was ist mit den komplexen Prüfungen, die bei unseren GreenScreens ablaufen und mit von verschiedenen Eingaben abhängigen Aufrufen weiterer Screens, was wir bei uns durch den das Verwenden von mehereren Formaten innerhalb eines Dialogprogramms realisiert haben. Diese Prüfungen will keiner Aufbrechen, da bereits bei unseren Anwendern das nötige KnowHow fehlt um zu definieren, wie die Abläufe zusammenhängen.

Hallo Andreas,

und das ist doch genau das Problem................

Ich stelle doch kein ( nur wegen der GUI ) System das
keiner anfassen will auf eine Webumgebung um.
In ein paar Jahren habe ich doch die doppelten Probleme.

Also:
Investieren in Ausbildung , Training, Schulung und Mitarbeiter.

Wenn man das nicht tut, kommt sowieso bald
die SW mit den drei Buchstaben. Bevor es aber dazu kommt
würde ich in die oberen Faktoren investieren, denn das ist allemal besser und von den Kosten her günstiger.

Gruß
Michael

[Logic IT-Services]

Profound Genie verfügt auch über ein Designtool mit welchem die umgesetzten Oberflächen mit zusätzlicher Funktionalität versehen werden können, ähnlich dem ProfoundUI Designer. Das heisst, normale Eingabefelder z.B. können als Combo-/Selektboxen erstellt werden, Grids und Bilder eingefügt werden und vieles mehr. Hier steht eine Anzahl an Widgets zur Verfügung. Profound Genie ist auch für Cobol geeignet.

Apropos Grids:
Einen Grid einzufügen, verlangt in ProfoundUI/Genie nach keiner einzigen Programmierzeile.

[Logic IT-Services]

Hallo,
das Problem mit neuem ist bei uns eigentlich ein anderes. In dieser Cobol-Anwendung steckt unheimlich viel Buisness-Logik, die die Prozesse unserer Anwender unterstützt und diese Logik wollen und können wir nicht aufbrechen. Beim Können scheitert es sowohl an zeitlichen als auch fachlichen Resourcen-.
Gruß
Andreas

p.s. ich möchte einfach eine "einfache" Lösung für die Ablöse unserer GreenScreen-Umgebung.

Das entspricht genau der Erfahrung, warum solche Projekt zurückgestellt oder nicht realisiert werden - zu komplex, zu teuer, keine Zeit. Dies ist übrigens auch ein Mitgrund, warum es EGL in der System i Welt so schwer hat.

[nico1964]

Vielleicht findes Du etwas Zeit, dieses PDF mit dem Suchbegriff "COBOL" durchzugehen: IceBreak Programmers Guide

Gruß,
Robert

Hallo Robert,

habe mal einen kurzen Blick darauf geworfen und festgestellt, daß dieses was für uns sein könnte. Dazu ein paar Fragen:
1. Wie hoch in etwa wäre der Schulungsaufwand(gestandene i-series Programmierer mit je ca 15-20 Jahren Erfahrung)
2. Ungefähre Kosten, da ich diese meinem Vorgesetzten mitliefern muss, denn die Entscheidung treffe leider nicht ich.
Gruß
Andreas

[holgerscherer]

Diese Prüfungen will keiner Aufbrechen, da bereits bei unseren Anwendern das nötige KnowHow fehlt um zu definieren, wie die Abläufe zusammenhängen.

Das ist die klassische Situation, weshalb wir unsere XTendGUI als reinen ScreenScaper mit externer Script-Möglichkeit konzipiert haben: keine Änderung an der AS/400 Software nötig, weil da keiner reingreifen will (oder gar den Sourcecode nicht hat). Da kann man zumindest die Optik anpassen, weil bei manchen Kunden der GreenScreen unbedingt weg muss (zum Beispiel im Verkaufsraum).

Sobald man eine komplexere Lösung in Angriff nimmt, inklusive Anpassung und Erweiterung der AS/400-Software, steigen Kosten und Aufwand gewaltig, so dass man eine Neuprogrammierung oder Neuanschaffung auch in die Betrachtungen mit einbeziehen sollte.

Meiner persönlichen Meinung nach sind viele Browser basierten Ansätze zwar hübsch, aber nicht unbedingt für den hausinternen Gebrauch geeignet. Die Haus internen Anwender brauchen die Betriebssystemunabhängigkeit nicht, der Client wird ja betreut. Und externe (Gelegenheits-)Anwender können eine besondere Web-Anwendung benutzen.

Nach über 10 Jahren GUI oder NichtGUI kann man nur sagen: nichts genaues weiss man nicht, die optimale Lösung gibt es nicht, und so mancher Anwender will den GreenScreen behalten...

-h

[Pikachu]

Da kann man zumindest die Optik anpassen, weil bei manchen Kunden der GreenScreen unbedingt weg muss (zum Beispiel im Verkaufsraum).

Manchmal tut's auch schon, die Farben umzustellen, und der GreenScreen sieht dadurch viel hübscher aus, und die Anwendungen sind immer noch genauso schnell und sicher zu bedienen.