Seltsames verhalten

[Robi]

Moin zusammen,

ich habe hier eine alte LF mit 3 Key - und einem select Feld

K Key1
K Key2
K Key3
S KZZE EQ 0

Select * from LF zeigt sofort die vorhandenen 15 Sätze

Key1 ist 7P 0
POST1 auch

1. Die meisten Übersichtsprogramme starten mit:
eval POST1 = *loval
....
POST1 Setll LF

Wenn ich das laufen lasse bekomme ich:
Das Ziel für eine nummerische Opperation ist zu klein um das Ergebnis zu halten
bei dem Setll !

2. Pgm angepasst und statt POST1 Setll mache ich ein*loval setll
UMWANDLUNSFEHLER:
Faktor 1 ist für die angegebene Operation ungültig!

3. Pgm angepasst, statt *loval setll mache ich nun 0 setll
Der anschließende Read geht auf EOF

4. Pgm angepasst, statt 0 setll mache ich nun 1 setll
Der Read braucht ca 17 Sekunden, dann zeigt er die Daten

Und ich überlege ob es gesten nicht 1 Glas Wein sondern ein Fass war!

Kann da jemand erklären?
Wie gesagt, auch hier werden Pgmme immer kopiert und angepasst, das ist in x Pgmmen so und funktioniert.

Danke!

[B.Hauser]

Hast Du schon einmal versucht statt *LOVAL/*HIVAL (*START/*END) zu verwenden?

Aus der ILE RPG Referenz:
The following reserved words are used for positioning database files. *START positions to beginning of file and *END positions to end of file.
*END
*START

Figurative constants can also be used to position the file. However, there are some situations where using *LOVAL or *HIVAL does not position the file exactly at the first or last record in the file; it is better to use *START and *END if you want to position to the first or last record in the file.

Hat die physische Datei vielleicht viele gelöschte Datensätze?
Vermutlich werden zunächst die gelöschten Datensätze gelesen (und überlesen) bevor dann der erste Satz gefunden wird. Deshalb dauert es so lange.
Mit *START sollten diese Sätze übersprungen werden.

[Pikachu]

Wie ist Key1 in der LF definiert (siehe DSPFFD LF)?

[Pikachu]

Wie ist die LF ins Programm eingebunden?

[Pikachu]

Zeigt das SQL-SELECT defekte Daten in der LF?

[Fuerchau]

Der SETLL liest auch die Schlüssel Key1, Key2, Key3 um für einen nachfolgenden READE/REDPE gewappnet zu sein.
Der Fehler kann also auch die anderen Schlüsselfelder betreffen.
Hinzu kommt noch die Selektion KZZE = 0.
Ggf. gibts da u.U. fehlerhafte Inhalte, ins besonders bei autocast, wenn das KZZE nicht numerisch sein sollte. Dies erklärt übrigens auch die lange Lesedauer des 1. Read. Das deutet darauf hin, dass der Index u.U. noch gar nicht aufgebaut ist.
Dies kann man bei DSPFD der LF sehen, ob zu den Schlüsseln Key1-Key3 auch eine Anzahl Knoten ausgewiesen werden.

[Pikachu]

Ist ein numerisches Feld mit gleichem Namen aber anderer Länge als in der LF auch im Programm selbst definiert?

[Robi]

@alle Danke

@Birgitta
viele gelöschte hat die Datei, das stimmt
*start versuch ich, dauert ...


@Pikachu (1)
Natürlich:rolleyes:

@Pikachu (2)
'Normal'
F Dateiname U F E K Disk (Update, vollprozedural, ext.beschrieben, keyed,)

@Pikachu (3)
Nein

@Baldur
Die Datei hat keine (für mich feststellbaren) Fehler.
Kein Null, keine dec err,
Die Datei ist in (schon ewig nicht mehr gewandelten) Programmen, täglich in Benutzung

@Pikachu (4)
Nein



Die (Test) Datenlib hat sich am WE neu erstellt.
mal sehn ob der fehler noch da ist.
*Start werde ich auch mal versuchen.
Wird n Tag dauern

[RobertMack]

Prüfe auch mal, ob die
DS POST1 über
K Key1
K Key2
K Key3
unsauber ist oder fehlt.

[Pikachu]

Ist die Datei wirklich als F Dateiname U F E K Disk eingebunden? Ist das K wirklich vorhanden?