Opnqryf

[Thimi]

Hallo Forum,
ich habe mit OPNQRYF ein kleines Problem, nämlich mit der Funktion %Xlate in Verbindung mit der TBL QSYSTRNTBL werden Umlaute v. LOWER/UPPER nicht übersetzt.
Weiß jemand Rat?

Schöne Grüße aus Hamburg
Thierry

[TARASIK]

Hallo Thierry,

vielleicht hilft Dir dies:

QCASE256 table in library QUSRSYS

Gruss TARASIK

[Thimi]

Moin TARASIK,

QCASE256 habe ich schon mal ausprobiert, leider ohne Erfolg.
Gruß
Thierry

[TARASIK]

Hallo Thierry,
hier das komplette Dokument aus meiner Datenbank:

Simple way to retrieve mixed-case data

John Kohan
07 Nov 2001, Rating 4.17 (out of 5)
Last month I spoke on translating text, and one of the examples I used was a lowercase to uppercase translation within your RPG program.
This month I would like to address another way to deal with mixed-case text by retrieving the key field and ignoring the case it is currently in.
Say we have a physical file that contains a name and address and we want to store the name in mixed case. Now, when the user selects the name he wants, the system needs to retrieve the requested record ignoring the case.
An example of this would be storing the last name of a person like "Smith" but retrieving the record by using "SMITH".
This can be accomplished by placing an alternate sequence in the DDS of a logical file or a physical file. This is a file-level keyword. Below is how you would define the DDS.
|...+....1....+....2....+....3....+....4....+....5 ....+....6....+....7....+....8
00010A ALTSEQ(QSYSTRNTBL)
00020A R RCUST PFILE(CUST)
00030A LASTNAME
00040A FIRSTNAME
00050A ADDRESS
00060A CITY
00070A K LASTNAME
00080A K FIRSTNAME
By setting an ALTSEQ, the view of this data will translate the text from lower to upper, so the case is basically ignored. The sort of the sequenced view would place the "SMITH" and "Smith" next to each other. This works very well for report and subfile displays.
When setting up a table, each 2-byte position in the table corresponds to a character. To change the order in which a character is sorted, change its 2-digit value to the same value as the character it should be sorted equal to. IBM has provided QCASE256 table in library QUSRSYS for you. This will do the lowercase to uppercase translation.
This technique is a simple and easy way to translate text without placing additional lines of code within your program. The simpler the code, the easier it is to maintain later.

Gruss TARASIK

[jajonowak]

Hallo Thierry,

mit dsptbl kannst du dir die tabelle anzeigen lassen. bei v5r1 werden die umlaute nicht umgesetzt z.b. ö (6a) wird nach 6a umgesetzt. da gibt es nur die möglichkeit eine andere tabelle zu finden, oder selbst eine erstellen.

LG Hans-Joachim

[Thimi]

Vielen Dank für die Hilfe, aber ich komme trotzdem nicht weiter.

@TARASIK
Mit der Umsetzungstab. QCASE256
und Eingabe FEUER* werden folgende Datensätze ausgewählt

77777770000 Feuerlöscher
00159N FEUERLOESCHERADAPT
10275N FEUERLÖSCHERHALTER
11478N FEUERLÖSCHERHALTER
05924N FEUERLÖSCHERHALTER
05925N FEUERLÖSCHERHALTER

Bei Eingabe FEUERLÖSCHER*
werden keine Sätze ausgewählt.

@Hans-Joachim
DSPTBL gibt es bei mir nicht sowohl unter 4.4 als auch unter 5.2

Gruss
Thierry

[jajonowak]

sorry, muss wrktbl sein

mfg hans-joachim

[Fuerchau]

Welche CCSID hat dein JOB !?
Welche CCSID hat deine Quelle !?

Ich nehme mal an, dass dein Hexcode des Ö nicht der gleiche ist wie durch %XLATE erzeugte.

Hier zeigt sich wieder die Stärke von SQL:

select .... where upper(myfield) like 'FEUERLÖSCHER%'

Bedenke aber, dass dieser Zugriff nicht der schnellste sein wird !

[Thimi]

Hallo Fuerchau,

ID des codierten Zeichensatzes (CCSID) . . . . . : 65535
Standard-ID des codierten Zeichensatzes . . . . . : 273

Die Quelle hat die gleiche CCSID

>Bedenke aber, dass dieser Zugriff nicht der schnellste sein wird !

Drum benutze ich OPNQRYF

Durch Patchen der QCASE256 hat sich das Problem somit erledigt

Tausend Dank für die Hilfe

schöne Grüsse aus HH.

Thierry

[Fuerchau]

Mit der Schnelligkeit meine ich nicht das spätere Programm. Auch OPNQRYF verwendet intern die selben Methoden wie SQL oder Query.
Wenn du also mittels %XLATE etwas suchst kann niemals ein Zugriffspfad verwendet werden, so dass immer die gesamte Datei verarbeitet werden muss. Bei ein paar 1000 Sätzen geht das ja noch, aber ab 100.000 Sätzen sinkt die Leistung drastisch.

Nimm lieber eine LF in der du eine Sortierfolge *LANGID verwendest. Dann kannst du problemlos per Programm darauf zugreifen bzw. wenn du OPNQRYF verwenden willst kannst du %RANGE('ABC' 'ABC999999') verwenden.

[Sven Schneider]

Um ein Missverständis auszuräumen :

OPNQRYF und SQL-Select nutzen die selbe Classice Query-Engine (CQE).
Damit gibt es auch keine Performence-Unterschiede bei gleichen Abfragen.

Lediglich ab V5R2 wird für bestimmte SQL-Abfragen eine neue optimierte SQL Query-Engine (SQE) benutzt.

Dies trifft bei SQL definitiv nicht auf Abfragen mit Like in der where-Klausel zu!!!

siehe :
http://www-1.ibm.com/servers/eserver...s/db2/sqe.html
http://www-912.ibm.com/n_dir/nas4apa...ight=0,II13486

Sven

[Fuerchau]

@sven

Dein 1. Link kann leider nur von Pro-Kunden angesehen werden.

Das Problem der Laufzeit betrifft ja auch nicht die LIKE-Funktion sondern die XLATE-Funktion auf die die Where-Bedingung wirken soll.
Da mittels XLATE erst mal alle Sätze übersetzt werden müssen um dann ggf. keine Sätze zu finden halte ich für fraglich bezüglich eines performanten Designs.

Mittels einer SORTSEQUENCE nach Sprache spare ich mir die Like-Klausel da ich mit %RANGE bzw BETWEEN arbeiten kann. Hier ist dann ein Zugriffspfad verwendbar.