View Full Version : guisierung des green screen
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
14-06-12, 14:06
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
14-06-12, 14:13
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.
Vielleicht findes Du etwas Zeit, dieses PDF mit dem Suchbegriff "COBOL" durchzugehen: IceBreak Programmers Guide (http://www.icebreak.org/Filer/IceBreak%20Programmers%20Guide.pdf)
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
15-06-12, 07:56
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
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.
RobertMack
15-06-12, 09:04
Hallo Andreas,
unter gestandenen iProfis sitzt das in zwei bis vier Tagen. Inklusive Erarbeitung einer hauseigenen optischen Erscheinung und Vorgehensweise (z.B. Nutzung der Wizards (http://www.robertmack.de/ComponentWizard.jpg), mehrfach verwendete Formate als Copystrecken, etc.). Dieses Beispiel (http://www.robertmack.de/IceBreakSbs.jpg) wurde in nicht einmal zwei Stunden erstellt.
Die Lizenzgebühren sind abhängig von Maschinengruppen. Kannst mir ja mal die Modellnummer mailen, dann hast Du konkrete Zahlen.
Übrigens muß man IceBreak nicht gleich kaufen. Wenn man wie Ihr die Entwicklung im Hause hat (Investition UND Eigenaufwand belastbar einschätzen will) macht es durchaus Sinn a) zunächst die Probezeit auf bis zu drei Monate verlängern zu lassen und b) danach IceBreak auf unbestimmte Dauer monatlich zu mieten.
Gruß,
Robert
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
Hallo,
genau das ist bei uns der Fall, haben Anwender, die seit über 10 Jahren glücklich mit grscr arbeiten, nur die jungen wollen das neue und unsere chefs. Sie wollten mir eine Testversion schicken, ich sende ihnen noch meine MailAdresse
Gruß
andreas
Ein sehr interessanter Beitrag zum Thema 5250 vs GUI. (http://groups.google.com/group/comp.sys.ibm.as400.misc/msg/5ff2c2c255a42e49)
RobertMack
15-06-12, 12:08
Danke, wirklich sehr interessant!
"The users *HATED* the gui interface, it was too slow (ODBC), too flaky (NS/router), and too resource intensive(VB). Our Operations people hated installing and supporting all the pieces. Our programmers hated coding it(Too much busy work. No version control)."
Genau das ist der Grund, warum IceBreak Anwender gerne "alles" native auf der i behalten. Im eigenen Subsystem, als reguläre i-Sourcen und Objekte, um ein Vielfaches performanter als Apache & Co.
Die Zahl der Anwender weltweit ist bereits dreistellig. Nur in D/A/CH braucht man öfter mal etwas länger ;)