char to num

[B.Hauser]

@Birgitta

Im Gegensatz zu RPG liefert ILE im Standard aber einen Dezimalfehler wenn die Zeichen keine numerische Tetrade haben !
Mit der Option FIXNBR(*ZONED:*INPUTPACKED) muss ich die Meldung dann ausschalten und es funktioniert dann auch, was aber ggf. zu unerwünschten Nebenwirkungen bei allen anderen Befehlen führt.

Mit der SRTSEQ und SQL zur Laufzeit ohne die Verwendung einer LF mit der passenden SRTSEQ erzwingt dies aber immer einen Tablescan bzw. Zugriffspfadaufbau !
Wobei ich auch hier mit dem Optimizer etwas auf Kriegsfuß stehe, denn der konnte nicht dazu bewegt werden, diese LF dann auch zu verwenden.
Das Handbuch Index Strategy (übrigens von 2003!) ist da auch leider keine Hilfe.

@Fuerchau

Du meinst also z.B. XYZ mit den Hex-Werte E7,E8,E9 würden zu einem Dezimal-Datenfehler führen. Bei mir werden ALLE Buchstaben (mit Ausnahme von ÄÖÜ, was auch in RPGIII nicht funktioniert) konvertiert und zwar ohne Dezimaldaten-Fehler und ohne Angabe von FIXNBR.

FIXNBR wird dazu verwendet, um Schrott in Datei-Feldern einlesen und verarbeiten zu können. Ungültige numerische Werte werden übrigens zu *Zeros! konvertiert.

Dass der Optimizer keinen Zugriffs-Pfad findet ist mir schon klar. Nur bevor man über irgendeine Schrott-Konvertierung eine Pseudo Sortierung zusammenpfuscht, denke ich sollte man doch einen Table-Scan in Betracht ziehen.

Birgitta

[Fuerchau]

@Birgitta
Was den Dezimalfehler angeht, probier doch obige Quelle einfach aus.
Im RPGIII gibt es generell keinen Fehler, egal welche Zeichen verwendet werden. Ungültige Zeichen werden einfach zu 0 konvertiert.
Im RPGIV gibt es nur Fehler, wenn FIXNBR nicht gesetzt ist und keine Zahl ermittelbar ist. Ansonsten wirkt FIXNBR auf ALLE Dezimalfehler des Programmes und nicht nur auf Eingabefelder und wirkt dann genauso wie bei RPGIII.

Was muadeep's Problem angeht, gebe ich dir allerdings vollkommen Recht !