Scheife wird nicht erkannt

[Steven]

Hi *ALL,

erstmal zu der kleinen Diskussion über mich. Also ich muss sagen das ich wohl wirklich viele Sachen gefragt hab, die nicht nötig gewesen wären. Also sorry!

Jetzt zum Problem. Ich tüftel da schon den ganzen Tag dran (und es is atm. kein Ausbilder da):

Ich hab immernoch das Subfile PGM. Ich habe ein DSPF bei dem ganz links ein eingabefeld mit für eine Zahl, und dahinter eine Zeile mit einem Datensatz. Wenn ich jetzt z. B. 4 eingebe, dann soll der entsprechende Datensatz in einer Subroutine gelöscht werden und zuvor ein Abfragefenster erscheinen. Aber genau das passiert nicht. Es ist so als ob die DOW-Schleife gar nicht vorhanden wäre. An den Fenstern liegt es auch nciht, weil ich es auch mit anderen Funktionen versucht habe.

Hier mal der Code:

C MOVE *ZEROS BLKN01

C DOW *IN70 = '0'
C READC SUBF01 70
C SELECT
C WHEN AUSW = '2'
C EXSR UPDATE
C WHEN AUSW = '4'
C EXSR DEL
C ENDSL
C ENDDO

SUBF01 = Subfile
AUSW = Das Fenster zur Funktionszahlen eingabe.

Ich verstehe das nicht, weil es in einem anderem Programm mit genau diesem Code funzt.

[mk]

Hallo Steven,

der Readc liest nur geänderte Subfilesätze.
Also nur wenn tatsächlich ein Subfilesatz z.B. mit 2 geändert wurde.

gruss michael

[Steven]

Welchen READ brauch ich dann da? Einfach READ oder READE ist ja nicht möglich.

[Fuerchau]

Ich glaube, dein Problem liegt in der Definition deiner Subfile in der DDS (DisplayFile)!

Wenn das Schlüsselwort SFLNXTCHG nicht angegeben ist, funktioniert READC nämlich nicht, da ein Änderungsflag nicht gesetzt wird.

Tip: SFLNXTCHG mit Bezugszahl definieren !
Wenn beim UPDAT diese Beszugszahl an ist, wird dieser Satz beim nächsten READC-Zyklus wieder gelesen.
Grund: Wenn eine falsche Auswahl vom Bediener eingegeben ist, sollte eine Fehlermeldung ausgegeben werden, der Cursor auf den falschen Satz positionieren (SFLCSR).
Nur der UPDAT mit Bezugszahl für SFLNXTCHG an sorgt dafür, dass dieser Satz immer wieder gelesen wird, auch wenn der Bediener nichts ändert.
Fehlt der UPDAT kann der Bediener eine falsche Auswahl eingeben und es passiert solange nichts, bis der Bediener genau diesen Satz wieder ändert.

[ERTH]

Hallo,

wenn ich den Code sehe, fällt mir auf, dass Du eine DOW-Schleife mit der Bezugszahl vom READC verwendest! Wenn die Bezugszahl *IN70 schon auf *ON (vielleicht anderer Lesevorgang?!) ist, dann geht das Programm nicht in die Schleife!
Mein Programm zur Verarbeitung von Eingaben in Subdateien würde so aussehen:

C MOVE *ZEROS BLKN01

C READC SUBF01 70

C DOW *IN70 = '0'
C SELECT
C WHEN AUSW = '2'
C EXSR UPDATE
C WHEN AUSW = '4'
C EXSR DEL
C ENDSL
C READC SUBF01 70
C ENDDO

[Steven]

Ich verwende *IN70 nur bei diesem Vorgang. Es funktioniert jetzt auch. Wegen nem falschen Tag hat er keinen Satz gefunden.

Aber warum verwendest du ganz unten vor ENDDO nochmal

C READC SUBF01?

thx 4 answers

[Dieser Beitrag wurde von Steven am 24. Oktober 2002 editiert.]

[B.Hauser]

Hallo Steven,

es gibt mehrere Arten mit einer Lese-Schleife zu arbeiten.
Welches die Beste ist, darüber streiten sich die Geister:

1. Möglichkeit:
Setll
Do *Hival
Read File
If %EOF
leave
endif
Verarbeitung
Enddo

2. Möglichkeit
setll
read File
Dow Not %EOF
Verarbeitung
read File
enddo

2a. Statt SETLL und read einen CHAIN benutzen.

Ich persönlich bin für die 1. Möglichkeit, da bei zukünftigen Änderungen, z.B. bestimmte Sätze müssen überlesen werden, das Programm leicht durch eine zusätzliche ITER-Bedingung geändert werden kann.
M.E. ist die Struktur bei Variante 1 leichter zu erfassen.

Viele Programmierer ziehen die zweite Variante vor, weil man gelernt hat, dass GOTO zu vermeiden ist. Für viele sind LEAVE und ITER Statements verkappte GOTOs, die umgangen werden müssen.
Der Nachteil bei Variante 2 ist, dass, bei Programm-Änderungen immer in die Tiefe geschachtelt werden muss und spätestens beim 3. If wird es unübersichtlich.

Aber wie gesagt zu diesem Thema gibt es unterschiedliche Meinungen.

Noch eine Anmerkung:
Wenn Du in RPGIV programmierst, kannst du bei Lese-Operationen (READ/READE/READP/READPE) auf die Gleich- Bezugszahl verzichten und stattdessen %EOF(File) abfragen:
1. Beispiel mit Gleich-Bezugszahl
Read File 92
If *In92
leave
EndIf

2. Beispiel mit %EOF
Read File
If %EOF(File)
leave
endif

Der Vorteil ist, man kann fremde Programme leicht ändern/erweitern, ohne prüfen zu müssen, ob die Bezugszahl bereits verwendet wird.

Überigens ab Release V5R1M0 kann RPG in Free Format geschrieben werden. Und im Free Format können die Hoch/Nieder/Gleich-Bezugszahlen nicht gesetzt werden!

Birgitta

[Steven]

thx für den Tipp

[malzusrex]

vorsicht bei %eof!
ich hatte damit neulich ein paar probs unter v45 (mit v5r1 lief alles normal)

key1 chain File1
dow not %eof(File1)

key2 chain File2
Dow Not %EOF(File2)
Verarbeitung
read File2
enddo

read file1
enddo


soweit so gut, jetzt war nur das problem, das die innere schleife genau einmal geklappt hat. beim 2. chain auf die File2 setzte er den %eof(File2) nicht zurück !!!
das chain durch ein setll/read ersetz ging dann wieder.

cu ronald

[B.Hauser]

Hallo,

zur Klarstellung:
1. Bei READ/READE/READC/READP/READP kann der %EOF bedenkenlos abgefragt werden.

2. Für CHAIN/OPEN/SETGT/SETLL kann der %EOF erst ab Release V5R1M0 abgefragt werden.
Der %EOF(FILE) wird auf *OFF gesetzt, wenn die Operation erfolgreich war, anderenfalls bleibt %EOF(FILE) unverändert.
%EOF ohne Parameter darf nicht abgefragt werden, weil er unverändert bleibt.
Beispiel:
1. Key Chain FILE
If not %EOF(FILE)
2. Key Chain File
if not %EOF
Im ersten Beispiel wird ein Satz gefunden und in die If-Verarbeitung verzweigt.
Im zweiten Beispiel wird ein Satz gefunden, jedoch nur in die IF-Verarbeitung verzweigt, wenn %EOF in einem vorgelagerten Statement gesetzt wurde.

Bei CHAIN wird %FOUND auf *ON gesetzt, wenn der Satz eingelesen wurde.

Bei SETLL zeigt der %EQUAL an, dass ein Satz mit dem gleichen Schlüssel gefunden wurde, was dem %FOUND bei CHAIN entspricht.
Bei SETLL wird der %FOUND auf *ON gesetzt, wenn ein folgender READ erfolgreich wäre, das heisst jedoch nicht, dass ein Satz mit dem angegebnenen Schlüssel gefunden wurde.

Birgitta

[malzusrex]

hallo birgitta,

besten dank für diese ausführliche schilderung zum %eof und co. ich muss doch immer wieder feststellen: "man(n) lernt nie aus".

tschau ronald