API zur Ermittlung des Parameter DFRWRT in einem Displayfile?

[schatte]

Hallo Leute,

ich würde gerne aus einem Programm heraus ermitteln, wie der Wert DFRWRT (Schreiben verzögern) für ein bestimmtes Displayfile gesetzt wurde.

Per DSPFD OUTPUT(*) wird dieser Wert angezeigt:

Schreiben verzögern . . . . . . . . . . . . : DFRWRT     *NO

Bei Ausgabe in Datei jedoch nicht. Auch die API QDFRTVFD liefert diesen Wert nicht zurück.

Gibt es eine andere API oder habe ich da etwas übersehen?

Gruß
Matthias

[BenderD]

... so ginge es auch:

CRTPF FILE(QTEMP/DFRWRT) RCDLEN(10)
OVRDBF FILE(STDOUT) TOFILE(QTEMP/DFRWRT)
qsh cmd('system ''dspfd mydspf'' | grep ''DFRWRT'' | cut -c ''62- 80''')

et voila:

DSPPFM QTEMP/DFRWRT

[Fuerchau]

Da scheint es wohl nichts zu geben.
Aber wofür ist das nötig ?

[schatte]

Schonmal Danke für die Antworten.

Fix eine bestimmte Stelle abzufragen ist natürlich immer problematisch, wenn die IBM ihr PRTF Layout ändert.

Wir brauchen diese Information für unsere grafische Oberfläche (Eigenentwicklung).

Gruß
Matthias

[Fuerchau]

Das muss man natürlich nicht verstehen.
Was hat eine grafische Oberfläche mit DFRWRT zu tun ?

[schatte]

Das muss man natürlich nicht verstehen.
Was hat eine grafische Oberfläche mit DFRWRT zu tun ?

Ich muss doch wissen, ob ich das Display beim WRITE schon auf dem grafischen Client Anzeige oder erst beim READ.

[Fuerchau]

Ich weiß ja nicht, wo deine grafische Oberfläche ansetzt.
Tauscht du die Read/Write/Exfmt gegen neue Calls aus oder setzt du auf virtuellen Terminals mit 5250-Datenstrom auf.
In beiden Fällen ist es eigentlich egal zumal es ja auf Satzformatebene auch ein entsprechendes Schlüsselwort gibt (z.B. Statusanzeigen ausgeben).
Beim 5250 steuert das die AS/400 selber, wenn du Calls verwendest muss das Programm eben entscheiden.

[schatte]

Ich weiß ja nicht, wo deine grafische Oberfläche ansetzt.
Tauscht du die Read/Write/Exfmt gegen neue Calls aus oder setzt du auf virtuellen Terminals mit 5250-Datenstrom auf.
In beiden Fällen ist es eigentlich egal zumal es ja auf Satzformatebene auch ein entsprechendes Schlüsselwort gibt (z.B. Statusanzeigen ausgeben).
Beim 5250 steuert das die AS/400 selber, wenn du Calls verwendest muss das Programm eben entscheiden.

Im Programm werden eigene Aufrufe zur Display Steuerung verwendet. Das eigentliche DDS wird in eine eigene XML Datei umgesetzt, die dann an den Client gesendet wird.

[Robi]

Ich muss doch wissen, ob ich das Display beim WRITE schon auf dem grafischen Client Anzeige oder erst beim READ.

ja natürlich, (oder doch nicht ?)

Wenn das bei euch wichtig ist ...
hast du mal ein Beispiel?
Ich hab nicht mal eine Idee, wofür das gut sein soll.

Hilf mir bitte mal
Robi

[Fuerchau]

Auf Datei und Satzformatebene kann man bestimmen, dass die Daten direkt beim Write ausgegeben werden und nicht auf READ/EXFMT gewartet wird.

Verwendet wird das (wie oben gesagt) zur Anzeige von Statusmeldungen, Refresh von Inhalten ohne das Programm anzuhalten.

[Robi]

Ok,
kann ich mir dunkel vorstellen.
Kommt aber in den Anwendungen die kenne nie vor.
War auch nie eine Anforderung oder wurde anders gelöst.

@Schatte
Wir haben unsere Anwendung auch selber 'Guifiziert' und eine tolle Java Oberfläche gebaut.
Grün läuft noch und Gui auch. Gui mit entsprechendem Mehrwert für die Anwender, Grün u.a. für Produktionsmitarbeiter, deren Hände nich für eine Maus gemacht wurden.
(Nutze für solche Aktionen die Möglichkeiten einer graphischen Oberfläche um z.B. eine 'Achtung' graphik in die Ecke zu malen)
Viel Erfolg.
Gruß
Robi

[Fuerchau]

Ist ja schön, dass es mal wieder eine grafische Oberfläche für die AS/400 mehr gibt.
Wofür die Leute so immer Zeit haben...