ILE Cobol: Satz löschen aus Subfile

[rebe]

Hallo!

Kann man in ILE Cobol einen Satz direkt aus einer Bildschirm-Subfile löschen? Oder muß man sich um das Löschen selber kümmern und die Daten in dem zu löschenden Satz mit den Daten des Folgesatzes überschreiben und den letzten Satz dann irgendwie leer schreiben?

Bin für Hinweise sehr dankbar.

Schöne Grüße
Reiner

[Fuerchau]

Leider geht das Löschen aus einer Subfile nicht.
Die einfachste Lösung ist hier, per Bezugszahl SFLCLR zu setzen und die Subfile neu laden.

[B.Hauser]

Hallo,

Die einfachste Lösung ist hier, per Bezugszahl SFLCLR zu setzen und die Subfile neu laden.

Eine Lösung in dieser Form hat einen entscheidenden Nachteil:
Alle noch nicht abgearbeiteten Optionen gehen flöten.

Sollen die Optionen beibehalten werden, müssen die Optionen, und die eindeutigen Schlüssel-Felder zwischengespeichert werden. Anschliessend wird die Subfile neu aufgebaut und die Optionen werden dem entsprechenden Subfilesatz zugeordnet.

Die Sicherung kann erfolgen in:
1. einer 2. Subfile
2. einer DataQueue
3. einer Feldgruppe

Die eleganteste Möglichkeit ist jedoch, statt einer Subfile UIM-Panels zu verwenden.

Birgitta

[loeweadolf]

Hallo,

Die eleganteste Möglichkeit ist jedoch, statt einer Subfile UIM-Panels zu verwenden.

Birgitta

Hallo Birgitta, gibt es bei SSS oder anderswo spezielle Schulungen für UIM-Panals ?

mfg: Ludger

[malzusrex]

Hallo Ludger,

sprech doch einfach mal den Michael Augel von SSS an, der hilft dir bestimmt weiter. mir hat er mal in einem (ne stunde oder mehr ..) crash--kurz per telefon gegeben. für ne keine anwendung hat es gereicht.


gruß ronald

[Fuerchau]

UIM-Panels sind eigentlich sehr schön zu verwenden, wenn man Screens wie OS/400-Screens aussehen lassen will. Es gibt sowohl verschiedene Erweiterungen (e.g. automatisch über mehrere Seiten) als auch komfortable Listensteuerung.

Über eines sollte man sich jedoch klar sein:

Man hat nur geringen Einfluss auf das Layout (1-Spaltig/2-Spaltig/Liste).
Man kann nicht mit MSG-Files zur Laufzeit arbeiten (Mehrsprachigkeit erfodert pro Sprache ein eigenes Panel).

Der Programmieraufwand ist ungleich höher als mit DSPF's, allerdings zwingt dies einen seine Programme stärker zu modularisieren.

Was die Listensteuerung angeht, so kann man sehr schön Einträge ändern, löschen und einfügen. Man kann automatisiert verschiedene Views (F10/F11) generieren ohne eigenen Code zu schreiben.
Bestätigungssubfiles (mit Mehrfachauswahl) erfordern keinen Programmcode.

Bestimmte Berechtigungen (Objekt/User) können direkten Einfluss auf das Layout haben.

usw. usw.

[B.Hauser]

Man hat nur geringen Einfluss auf das Layout (1-Spaltig/2-Spaltig/Liste).

UIM generiert 100% SAA-Standard.

Man kann nicht mit MSG-Files zur Laufzeit arbeiten (Mehrsprachigkeit erfodert pro Sprache ein eigenes Panel).

Das heisst jedoch nicht, dass mehrere Panel-Quellen für das gleiche Panel vorliegen müssen. In Panels können, wie Display-Files und Printer-Files Texte in Form von Message-Ids hinterlegt werden.

Die Display-Files sind die einzigen Objekte, die tatsächlich zur Laufzeit Texte aus Message-Files verarbeiten.
Arbeitet man mit Mehrsprachigkeit, muss man z.B. auch die Printer-Files für jede Sprache einzeln erstellen und zur Laufzeit das entsprechende Objekt verwenden. Idealerweise hat man für jede Sprache eine eigene Objekt-Bibliothek, die je nach verwendeter Sprache in die Bibliotheks-Liste eingefügt werden kann.

Der Programmieraufwand ist ungleich höher als mit DSPF's, allerdings zwingt dies einen seine Programme stärker zu modularisieren.

Programmier-Aufwand für Panel?
Das ist am Anfang etwas ungewohnt, aber ansonsten Übungssache und benötigt nicht mehr Zeit als jede normale Display-File.

Programmier-Aufwand für Programme?
Falsch! Die Steuerung wird von APIs übernommen. Man muss nur dafür sorgen, dass die Daten, die angezeigt werden und verarbeitet werden sollen, korrekt zwischen und über die verschiedenen APIs hin- und hergeschaufelt werden. Steht der Ablauf und die Reihenfolge, in der die APIs aufgerufen werden, einmal, braucht man nur den entsprechenden Datenbuffer auszutauchen, ein paar F-Bestimmungen austauschen und ein paar Prüfungen zu ändern, das war's.

Bei der Verwendung von Subfiles muss die Steuerung in jedes Subfile-Programm eigebunden werden. Und eine Subfile-Steuerung nach SAA-Standard, mit Bestätigungs-Subfile und korrekter Steuerung bei F12 und korrekter Positionierung ist schon ziemlich komplex.
Kaum wird ein Statement in der Steuerung gelöscht und verändert, läuft nichts mehr, und das Geschrei ist gross.

Bestätigungssubfiles (mit Mehrfachauswahl) erfordern keinen Programmcode.

Wohl aber Code im UIM-Panel.

Birgitta

[Fuerchau]

In großen Teilen stimme ich dir ja zu, Birgitta, aber leider haben manche Kunden den Wunsch möglichst viele Informationen (auch bei Subfiles) auf einen Blick zu sehen.
Da aber das Layout nur sehr eingeschränkt beeinflussbar ist, gibt es immer mal wieder Probleme in der Darstellung.
Besonders wenn ich mir MsgId's arbeite kommt es mitunter zu anderen Darstellungen da sich nicht immer an die Längenvorgaben gehalten wird. Bis hin zum Problem, dass das Panel auf einmal nicht generiert wird, weil die Liste die Breite von 80/132 auf einmal übersteigt.
Mehrzeilige Listen werden auch noch nicht unterstützt so dass man unbedingt Views benötigt um die Informationen darzustellen.
Die Cursorsteuerung (über Feldnamen) ist gewöhnungsbedürftig (hierzu gibt es auch andere Beiträge zu Cursor in DDS). Bei DDS bin ich immer noch ein Fan von Bezugszahlen, auch wenn man sie für den Rest der Programme nicht mehr benötigt.

Bestätigungssubfiles findet man bei CRM-Anwendungen auch eher selten.

Es wäre schön, wenn es für UIM-Panels auch mal einen SDA-ähnlichen Ansatz gäbe, aber daran glaube ich nicht.

Was die Komplexität angeht so ist meine Erfahrung dahingehend, dass es besser ist mit den EXIT-Funktionen zu arbeiten, da damit die Funktionen besser gekapselt werden können (1 Aufruf pro Funktion/Satz) als mittels Return und dann mal sehen was passieren muss.
In OPM-Umgebungen führt das zu mehreren Programmsegmenten, was sicherlich die Modularität steigert (bei ILE könnte man auch Funktionen als Exit's definieiren).

PS:
Für UIM-Panels hatte ich mal ein Testprogramm entwickelt, dass eine erstellte UIM mittels diversen Funktionen bedienen kann, so dass man nicht immer gezwungen ist sich durch das ganze Programm zu hangeln um an das gewünschte Layout zu kommen bzw. die diversen Exits (nur OPM) zu testen.
Da ich damals in COBOL entwickelte habe ich auch aus der UIM-Quelle die COPY's generiert zum Datenaustausch, was sich sicherlich auch auf (ILE)RPG erweitern ließe.