AS400 - Window verschwindet

[woy]

Danke, werde ich probieren

A 93 SFLCLR

muss ich also nach dieser Angabe was genau angeben?

A RSTDSP(*YES)

eingeben?

[Fuerchau]

Auch das Thema findet sich immer wieder hier.
RSTDSP(*YES) betrifft den eigenen Bildschirm, wenn dieser von einem CALL überschrieben wurde.
RSTDSP(*YES) ist, wenn keiner eingegriffen hat, sowieso der Default.

Mittels Schlüsselwort ASSUME auf einem eigenen, nicht verwendeten Satz, kombiniert nun die AS/400 beim Open den Inhalt deines Fensters mit dem aktuellen Inhalt.

Durch RSTDSP(*YES) deines DSPF wird nun nach Rückkehr der gesamte Inhalt wiederhergestellt.
Ohne ASSUME wäre hier RSTDSP(*NO) korrekt.
Dies führt aber z.B. beim Ausführen einer Abruftaste mit QCMD oder einem MSGBRK zu Problemen.

ASSUME ist für jedes DSPF mit ausschließlichen Fenstern meist erforderlich.

[Dschainers]

RSTDSP(*YES) ist nicht der Defaultwert beim CRTDSPF.
Default = *NO

Nochmal, ich würde auf der Befehlsebene mal

CHGDSPF 'Bibliothek/Bildschirmdatei RSTDSP(*YES)

eingeben.

und dann nochmal probieren.

[B.Hauser]

Füg' mal in Deine DisplayFile das folgende Dummy-Format ein (wird nie aufgerufen!) und erstelle Display-File und Programm neu.

A          R DUMMYFMT                             
A                                      ASSUME     
A                                 24 80' '

Birgitta

[woy]

Guten Morgen miteinander
Zuerst einmal vielen, vielen Dank für Eure Tips, finde ich super.

Brigitta: ja werde ich probieren

Dschainers: Sorry, ich hatte ja geschrieben, dass ich neu in dieser Umgebung bin, also bitte entschuldige meine wahrscheinlich naive Frage: Wo genau muss ich denn
CHGDSPF 'Bibliothek/Bildschirmdatei RSTDSP(*YES)
eingeben - was heisst "auf Befehlseben"?

Ich habe übriges einen weiteren Test gemacht. Wenn ich aus dem ersten Fenster kein weiteres Pgm/Fenster aufrufe, sondern den auszugebenden Wert in meinem ersten Pgm/Fenster direkt einstelle und dann das Fenster wie gewohnt ausgebe, fubktioniert alles bestens, d.h. der Hintergrund bleibt bestehen. Lange Rede kurzrêr Sinn, es funktioniert nur dann nicht, wenn ich ein zweites Fenster ausgebe

LG Günter

[B.Hauser]

Die Situation, dass das der Hintergrund verschwindet, sobald ein weiteres Fenster aufgemacht wird ohne zuvor in dem "Haupt-"Programm den Bildschirm erneut angezeigt zu haben (EXTFMT) ist alt bekann.
An dieser Stelle wird sich auch nichts mehr ändern, da der Stand der "green Screen"-Entwickung "stabilisiert" ist.

Birgitta

[Robi]

@ mit Read lesen nach Systemwechsel

Bin zwar kein Cobolaner, denke aber, wenn du die Datei zu macht und neu öffnest sollte das gehen.
Wir nutzen für diese Dinge (Für alle Dateizugriffe) 'Leseprogramme'.
D.H. ein PGM liest/schreibt Datei A System A, ein anderes Datei A System B
(SQL: Connect to ...)

So können wir immer nach Bedarf die richtige Datei vom richtigen System lesen

Ach ja, wenn wir nicht mit SQL zugreifen nutzen wir DDM Files dafür (aber auch mit Lesepgmmen)

Robi

[KingofKning]

Naja, ihr werdet doch auch noch eine Befehlseingabemöglichkeit haben. Da wo Du z.B. den strpdm eingibst gibst du dann den chgdspdf ein.BTW. Ich würde SQL-Aufrufe und normale Reads und writes nicht unbedingt kombinieren. Was spricht gegen ein SQL-Read?GG

[Fuerchau]

Nun werden hier mehrere Themen durcheinander geworfen:

1. Der Standard-Default für CRTDSPF ist RSTDSP(*YES) zumindest auf allen Systemen die ich kenne.
Wenn er anders ist, gibt's aus irgendwelchen Gründen einen CHGCMDDFT.
Ein RSTDSP(*NO) führt mitunter zu seltsamen Verhalten. Wenn eine Programm an Stelle von EXFMT nur Write/Read's verwendet (in COBOL geht das gar nicht anders), kann es mitunter vorkommen, dass bei "Unterbrechungen" der Bildschirm nicht korrekt wiederhergestellt wird. Das Programm wartet auf einem READ aber man kann keine Eingabe mehr tätigen, nochnicht mal F-tasten werden akzeptiert.
RSTDSP(*YES) verhindert dies.

2. ASSUME war schon immer nötig, wenn ein Programm ausschließlich ein Fenster mit Window bedient.
Jeder Open einer DSPF prüft, ob es bereits eine geöffnete DSPF im Callstack übergeordnet gibt. Dieser Inhalt wird beim Open gesichert und beim Close wiederhergstellt falls RSTDSP(*YES) im übergeordneten DSPF angegeben ist.
Dies führt daher zu dem Verhalten, dass die 1. Anzeige des Fensters klappt, ab der 2. Anzeige meistens nicht. Hier hilft mitunter ein USROPN, so dass ich eben OPEN/CLOSE durchführen muss.
Noch komplexer wird es dann mit mehreren Ebenen die alle nur Fenster verwenden.

3. SQL und Native-IO haben nichts gemeinsam. Ein SQL-Connect hat ausschließlich für SQL Bedeutung, normale Datei-Befehle merken davon nichts. Früher (funktioniert heute auch noch) verwendete man im Einzelnen DDMF's mit OVRDBF. Allerdings ist hier die Grenze bei 16 gleichzeitigen Open's und die Voraussetzung SNAoverIP.

[woy]

Hallo alle miteinander
Also auf jeden Fall vielen Dank für Eure Hilfe. Ist eine tolle Sache, das mit dem Forum.
Das Problem des verschwundenen Hintergrund habe ich jetzt so gelöste, dass das erste Window kein Window mehr ist und jetzt funktioniert alles. Hat mich zwar schon gewurmt, dass zweifache Fenster nicht möglich sein sollen, aber ganz pragmatisch ist eine funktionierende Lösung halt das Wichtigste.

Fuerchau: auch Dir besten Dank bez. SQL und Native IO, ok muss ich halt in diesen Fällen die SQL's einbauen.

Schönes Wochenende und wenn ich wieder Probleme haben sollte, weiss ich ja jetzt, wohin ich mich wenden kann

LG Günter

[Fuerchau]

Natürlich sind mehrere Fenster möglich.
Aber du brauchst in jeder DSPF ein Format mit ASSUME.

[woy]

Das habe ich auch und es funktioniert trotzdem nicht