char to num

[muadeep]

zu Pikachu:

weil ich dadurch eine andere Sortierfolge bekomme

anstelle von:
23
23
89
567
1234567
ABCD...
BBBB....
XYZ....

würde die Sortierfolge dann so ausehen:
ABCD...
BBBB....
XYZ....
1234567
23
567
89

[RobertMack]

Hallo,

das könnte man mit einem zusätzlichen Schlüsselfeld lösen:

0 23
0 89
0 567
0 1234567
1 ABCD...
1 BBBB....
1 XYZ....

0=WNR numerisch (TESTN)
1=WNR alphanumerisch

Gruß,
Robert

[B.Hauser]

Hallo,

das könnte man mit einem zusätzlichen Schlüsselfeld lösen:

0 23
0 89
0 567
0 1234567
1 ABCD...
1 BBBB....
1 XYZ....

0=WNR numerisch (TESTN)
1=WNR alphanumerisch

Gruß,
Robert

Das funktioniert aber nur, wenn die Einträge entweder nur aus Zahlen oder nur aus Buchstaben bestehen.

Außerdem sollte man mit TESTN vorsichtig sein, da die Buchstaben A-R auch als "numerisch" angesehen werden. Der Grund hierfür liegt darin, dass das erste Halbbyte, C, D oder F enthält und das zweite Halbbyte eine Ziffer zwischen 0 und 9 beinhaltet.
(F/C=Positive Zahl, D=Negative Zahl)

Birgitta

[Pikachu]

Hallo muadeep!

Wie soll denn die Reihenfolge der Datensätze im Detail genau aussehen?

Viele Grüße
Jürgen

[harkne]

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

[Fuerchau]

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 ?

[B.Hauser]

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

[Fuerchau]

@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.

[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 !