guisierung des green screen

[dschroeder]

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

[nico1964]

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.

Hallo
da würde mich interessieren, ob das ganze auch für komplexe Cobol-Anwendungen(Banken-bzw.Leasingbereicht) geeignet ist und was der Spass den ungefähr so kostet.
Gruß
Andreas

[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.

[woodstock99]

ähm ich nochmal .

frage webfacing. die programme werden bei webfacing in batchprogramme umgewandelt oder??
wie verhält sich da die performance im allgemeinen??

hab mittlerweile schon ein paar produkte gefunden aber was wirklich gut ist wird mir auch keiner sagen können oder??


goering.de
- LOCKSOFTWARE
Seagull.de
Bluezonesoftware.com
pks.de
ml-software.com/
lansa.com.au/de/index.htm
veda.net

[B.Hauser]

frage webfacing. die programme werden bei webfacing in batchprogramme umgewandelt oder??
wie verhält sich da die performance im allgemeinen??

Für Webfacing wird keine interaktive Leistung benötigt.
Wir hatten unsere Anwendung für einen Kunden umgesetzt, der sich eine Batchmaschine angeschafft hatte. Performancemäßig war ich positiv überrascht, d.h. die Anwenung lief nur unwesentlich langsamer als die Original-Green-Screen-Anwendung.

Birgitta

[woodstock99]

aber dafür müsste man sich dann so eine maschine anschaffen oder? weil ich denke auf einer wirds ziemlich schwierig oder??

[Fuerchau]

Bei Webfacing wird nix automatisch in Batch umgewandelt.
Das Produkt liefert der Anwendung virtuelle 5250-Terminals, so dass die Anwendung glaubt im Dialog zu arbeiten.
Die 5250-Daten werden dann eben in HTML übersetzt und im Browser ausgegeben, die Eingaben kommen eben auch wieder zurück.
Mit Guisierung hat das nur wenig zu tun, sondern ist im Wesentlichen eine Browserfähige 5250-Emulation, von denen es auch andere gibt.
Man kann natürlich die Dialoge dann schöner gestalten, aber ändert nicht das eigentliche Verhalten der Anwendung.

Gefährlich wirds dann, wenn DEVRCYACN(*DSCMSG) verwendet wird, da hier ggf. die Zuordnungen User/Terminal->Job nicht passen und sich somit geparkte Dialogjobs im System anhäufen.

Batch in diesem Zusammenhang bedeutet nicht, dass es sich dabei um Batchjobs handelt.
Der Job läuft weiter als Dialogjob, belastet aber anscheinend nicht mehr die Dialog-CPW.

[woodstock99]

also ich glaub jetzt mal deiner variante weil im internet stehen ja ein paar über dieses thema. hab deshalb auch gefragt weil ich die aussagen (nicht von dieser seite) nicht verstanden hab wie das funktionieren soll ,das die programme in batchprogramme umgewandelt werden usw .

also ich habs jetzt so verstanden.
meldet sich ein terminal an. kommt green screen , komm ich über den browser rein bekomm ich die grafische öberflache wobei keine dialog cpw verbraten wird sondern die geschichte im batchmodus abgewickelt wird.
das erledigt dann alles die schwarze liste für mich...
und vom programmieraufwand hält sich die geschichte auch in grenzen oder?

[RobertMack]

--------------------

[B.Hauser]

also ich habs jetzt so verstanden.
meldet sich ein terminal an. kommt green screen , komm ich über den browser rein bekomm ich die grafische öberflache wobei keine dialog cpw verbraten wird sondern die geschichte im batchmodus abgewickelt wird.
das erledigt dann alles die schwarze liste für mich...
und vom programmieraufwand hält sich die geschichte auch in grenzen oder?

Ich kann es nur aus meiner Erfahrung sagen.
Wir hatten ca. 800 Display-Files mit durchschnittlich 10-15 unterschiedlichen Formaten.
Insgesamt waren in diesen Display-Files zum damaligen Zeitpunkt 2 oder 3 Schlüsselworte enthalten, die nicht konvertiert werden konnten. Bei genauerer Prüfung hatte sich herausgestellt, dass diese Schlüssel-Worte nicht mehr erforderlich waren und eigentlich nur durch's Kopieren immer weitergegeben wurden. Diese Schlüsselworte musste in den Display-Files auskommentiert werden.

Nach dem das geschehn war konnte das Webfacing Projekt erstellt und die Display-Files konvertiert werden. Die Konvertierung selber hat eine ganze Nacht gedauert, wurde jedoch problemlos durchgeführt.

Danach kann man mit dem internen Server schon mal testen. (ggf. benötigt man noch ein kleines Start-Programm, das die Bibliotheksliste und sonstigen Schnickschnack setzt).

Anschließend kann man ein *.EAR-File erstellen, die Anwendung auf den Server packen und über den Browser arbeiten.

Programmanpassungen waren zu diesem Zeitpunkt nicht erforderlich.

Summa summarum hat mich diese ganze Aktion ca. 3 Tage gekostet. Gegenüber dem schwarz/grünen Bildschirm ist keine Funktionalität dazugekommen.

Das "Aufhübschen" ist das, was dann im End-Effekt Zeit kostet, da jede Display-File einzeln angefasst und bearbeitet werden muss. Je nach Anforderung muss dann auch das eine oder andere Programm angepasst werden. So war bei uns z.B. gewünscht, dass Fehlermeldungen in einem Fenster anstatt auf Zeile 24 ausgegeben werden.

Birgitta

[woodstock99]

danke britta für deine antwort ......