PDA

View Full Version : Altes RPG-Programm liest aus logischer Datei unvollständig oder in falscher Folge



msost
11-10-19, 12:49
Hallo zusammen,

ich habe S/36-Dateien extern definiert und ein dazugehöriges RPG/36-Programm in RPG gewandelt (keine Angst, RPGLE und Co kommen noch. Aber erstmal 1:1 umwandeln...). Dabei stoße ich auf folgendes Phänomen:

Das Programm liest Sätze aus einer logischen Datei und zeigt mehrere nach Kunden/Auftragsnr. sortiert an. Bei Bild auf wird die nächste Seite mit Sätzen angezeigt.

Das RPG/36 Programm zeigt zu einem Kunden 2 Seiten Aufträge an. Das RPG Programm zeigt die zweite Seite leer an.

Im Debug sieht man, dass in der Leseroutine ein SETLL auf den letzen Satz der ersten Seite gemacht wird und dann in einer Schleife weitergelesen wird. Allerdings wird ein Satz des nächsten Kunden gelesen, der dann das Schleifenende verursacht. Obwohl noch weitere Sätze zum gesuchten Kunden kommen müßten.

Kann es sein, dass ein RPG den Zugriffspfad ignoriert und z.B. nach relativer Satznr. liest?

In der F-Karte ist die Datei mit Key definiert, der auch dem Key der logischen entspricht:

FABWI UF F 420 42AI 1 DISK


I und O Karten sind noch intern definiert.

In der C-Karte erfolgt ein SETLL und eine Schleife mit READ:
C YIIND2 SETLLABWI
C Z-ADD0 Z
C*----------
C BL2100 TAG
C SETOF 21
C READPABWI 21
C 21 GOTO BL2500
C RIIND COMP YIIND 21
C N21 GOTO BL2500

Beim SETLL steht in YIIND2 der letzte Satz des ersten Bildschirms. Der erste Read liest aber bereits den ersten Satz des zweiten Kunden und der COMP macht die 21 an.

Hab schon über OPNQRYF nachgedacht, um die Reihenfolge der Sätze zu sichern, allerdings gibt es auch updates im RPG.

Könnte das ein generelles Problem sein?

Möchte ungern alles umschreiben, da es recht umfangreich ist.

Gruß

Matthias

camouflage
11-10-19, 13:24
Vielleicht SETGT und dann rückwärts lesen, also ich würd's nur mit der Kundennummer so machen. Wobei hängt auch ab, wie die Logische definiert ist.

B.Hauser
11-10-19, 14:08
Nur mal so eine Idee: liest Du auch wirklich geschlüsselt oder fehlt vielleicht das K in den F-Bestimmungen?

Birgitta

msost
11-10-19, 14:30
Hallo Birgitta, hallo Camouflage,

danke für die Ideen.

Ich hab's gefunden. Der Gesamtkey setzte sich aus mehreren Feldern zusammen. Zu Zeiten der S/36 konnte man ja mit EXTK auch Dateien verarbeiten, deren Schlüsselbereiche nicht zusammenhängend waren... Bei der Umsetzung des Gesamtschlüssels hab ich zwei Datumsfelder verwechselt, was dann zu dem komischen Leseergebnis führte.

@Birgitta: K in der F-Karte geht nur wenn sie nicht so wie in diesem Beispiel intern beschrieben ist.

Euch ein schönes Wochenende!