View Full Version : char to num
Hallo muadeep!
Wie soll denn die Reihenfolge der Datensätze im Detail genau aussehen?
Viele Grüße
Jürgen
ups,
sorry, ich vergaß zu erwähnen, daß das neue Feld ein "Komma"-Feld ist
also
-> WNR = 7a
-> NeuesFld = 9,2
wenn ich das WNR-Feld mit "MOVE" übertragen würde, dann würd ich immer einen "Dezimaldatenfehler" bekommen
Wäre es vielleicht möglich den genaueren Hintergrund zu erläutern. Es ist mir absolut unverständlich für was man so was braucht ? Ein siebenstelliges Characterfeld das nicht nur Ziffern beinhaltet in ein numerisches Feld mit Nachkommastellen zu übertragen und dann auch noch zu erwarten dass da kein Müll drin steht und den Müll dann auch noch in die DB zu pressen
Um den Vorschlag von oben nochmals aufzugreifen. Dann mach halt noch ein 7-stelliges Maskenfeld. An den Stellen an denen Buchstaben stehen ins Maskenfeld eine 1 und an den Stellen an denen Ziffern stehen eine 0.
Also z.B. so
Maske Feld
1100101 DD35X4
Sollen Leerstellen vor Ziffern kommen dann behandle die Leerstellen wie Ziffern also Maskenwert 0
Somit hast Du du auch die Möglichkeit solche Spielchen zu machen wie.
1. alle Ziffern
2. Leerzeichen
3. Großbuchstaben
4. Kleinbuchstaben
Dann verwendest Du als Maskenfelder nicht nur 0 und 1 sondern z.B. 1-4
Beispiel
Maske Feld
3421143 Dx 34xA
I DS
I I 1 92TNUM
C *ENTRY PLIST
C PARM XXALPH 7
C MOVELXXALPH TNUM
C TNUM DSPLY
C RETRN
Mit diesem kleinen Beispiel kann man erleben, dass meine obige Aussage stimmt !
Der MOVE ersetzt sämtliche Zeichen durch Zahlen, wichtig ist einzig, dass das Zielfeld initialisiert ist.
Alle Zeichen, die in der rechten Tetrade keine Ziffer enthalten werden mit 0 ersetzt.
Allerdings hilft das für obige Aufgabenstellung wenig, da damit Alpha-Werte in den Zahlwerten einsortiert werden.
Ausserdem:
Was hindert eigentlich jemanden daran, aus ILE ein OPM-Programm aufzurufen ?
Allerdings hilft das für obige Aufgabenstellung wenig, da damit Alpha-Werte in den Zahlwerten einsortiert werden.
Ausserdem:
Was hindert eigentlich jemanden daran, aus ILE ein OPM-Programm aufzurufen ?
Warum sollte man überhaupt ein OPM oder RPGIII Programm aufrufen, der MOVE funktionniert genau so auch in RPGIV (nur nicht im Free Format!)
@muadeep
ist Dir eigentlich klar, dass z.B. C und L die gleiche Wertigkeit (3) haben und damit lustig bunt durcheinander sortiert werden würden.
Wenn es nur um die Sortierung geht, könnte man mit embedded SQL die Sortierreihenfolge ändern. Diese gilt allerdings dann für alle SQL-Abfragen in diesem Programm. *LANGIDUNQ würde z.B. wie folgt sortieren 1-9, a-z, A-Z, wobei a und A als unterschieldiche Werte betrachtet werden. *LANGIDSHR würde genauso sortieren, nur Groß- und Klein-Buchstaben haben die gleiche Wertigkeit, d.h. wenn die nach Meier suchst, wird MEIER, mEier, meier gefunden.
C/EXEC SQL Set Option SrtSeq = *LangIdShr
C/END-EXEC
Birgitta
@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.
@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
@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 !