DB2 / SQL / String auf gültige Zeichen prüfen

[Fuerchau]

Ich würde den Parameter ebenso "varying" definieren und die For-Schleife darf nicht mit %trim() arbeiten.
Wenn mal Leerzeichen am Anfang stehen arbeitest du zu kurz.
Außerdem sollten diese ggf. ja nicht entfernt werden (siehe u'0020').

[Fuerchau]

Was soll die Abfrage

or ($ch >= u'00010000' and $ch <= u'0010FFFF');

Du hast doch kein UCS4.

[rissling]

Ich arbeite in der For-Schleife absichtlich mit Trim, da ich eine größere Menge Sätze bearbeite und das ganze spürbar langsamer wird, wenn man die gesamten 5000 Zeichen durchläuft, auch wenn evtl. nur 200 Zeichen belegt sind. So ist es wesentlich schneller und Leerzeichen am Anfang kommen bei mir nicht vor.

Ich habe die Abfrage so gebaut, weil in der Fehlermeldung unter https://www.ibm.com/support/knowledg...pc/n20377.dita alle erlaubten Zeichen angeben sind - diese habe ich so übernommen.

[Fuerchau]

Wenn du die PI-Variable mit Varying definierst, werden dir ja nur so viele Zeichen übergeben, wie die Quelle lang ist. Du arbeitest ja eben keine 5000 Zeichen durch!
Außerdem musst du folgendes beachten:
Der Aufruf kopiert deine Quelle in ein 5K-Feld und füllt mit Leerzeichen auf.
Die %trim() entfernt die Leerzeichen wieder, %Len() gibt dir die Länge, anschließend verwirfst du das Trim-Ergebnis wieder.
Übergibst du also z.B. " A", gibt deine Routine nur das Leerzeichen zurück.

Also:
Definiere PR/PI mit "varying const" und arbeite ohne Trim die Zeichen ab.

[B.Hauser]

Wenn du die PI-Variable mit Varying definierst, werden dir ja nur so viele Zeichen übergeben, wie die Quelle lang ist. Du arbeitest ja eben keine 5000 Zeichen durch!
Außerdem musst du folgendes beachten:
Der Aufruf kopiert deine Quelle in ein 5K-Feld und füllt mit Leerzeichen auf.
Die %trim() entfernt die Leerzeichen wieder, %Len() gibt dir die Länge, anschließend verwirfst du das Trim-Ergebnis wieder.
Übergibst du also z.B. " A", gibt deine Routine nur das Leerzeichen zurück.

Also:
Definiere PR/PI mit "varying const" und arbeite ohne Trim die Zeichen ab.

@1: Nur wenn ein Parameter im Prototyp/Procedure Interface mit VALUE definiert ist, werden Zeichen überbeben.
Sofern der Parameter by Reference übergeben wird (mit Schlüssel-Wort const oder ohne wie in dem Beispiel) wird nur die Adresse des Parameter-Feldes übergeben unabhängig davon, ob es mit fixer oder variabler Länge definiert wurde.
Die Angabe CONST bewirkt lediglich, dass bei abweichender Parameter-Definition ein zusätzliches Feld mit der erwarteten Parameter-Definition (bei UCS2(5000) sind das 10000 Byte und bei VarUCS2(100002) Byte erstellt wird und dann die Adresse dieses Hilfsfeldes an die rufende Prozedur übergeben wird.
Bei Feldern mit variabler Länge sollte man nicht nur CONST, sondern auch OPTIONS(*TRIM) angeben, damit führende und folgende Blanks gleich abgetrimmt werden.
Die Daten-Länge wird in den beiden führenden Bytes hinterlegt und beim Verarbeiten von Feldern mit variabler Länge geprüft.

Birgitta

[Fuerchau]

Const und Value sind quasi gleicharbeitend mit dem Unterschied das Const nicht geändert werden darf.
In beiden Fällen wird ein Variable (bereits im Compiler generiert) vor der Übergabe gefüllt.
Options(*trim) ist ganz nett sollte aber nicht grundsätzlich verwendet werden:
a) zusätzliche Laufzeit (@D*B: ja im Nanobereich)
b) kommt halt auf die Anwendung an
Leerzeichen (vor allem am Anfang) sind schon manchmal erforderlich.
Was die Performance angeht so sollte die Runtime so intelligent sein nur die benötigte Länge zu übertragen und nicht immer mit Leerzeichen auffüllen.
Aber das bleibt auszuprobieren.

[B.Hauser]

Baldur,

Lies doch mal die Dokumentation!

Es gibt sehr wohl einen Unterschied zwischen CONST und VALUE!

Parameter, die mit CONST übergeben wurden dürfen deshalb nicht geändert werden, weil nie sicher ist, ob der übergebene Pointer auf das Original-Feld oder das Duplikat zeigt.
Sofern keine abweichende Parameter-Defintion festgestellt wird, wird der Pointer auf das Original-Feld übergeben.

Bei VALUE wird IMMER eine Kopie des Original-Feldes erzeugt und dieses an die aufgerufene Prozedur übergeben.

Es wird immer die maximale Länge reserviert, das heißt jedoch nicht, dass diese komplett übergeben oder mit Blanks aufgefüllt wird.
Wie gesagt, die Übergabe erfolgt nur bei VALUE und dann die komplette Länge, was sich bei großen Feldern negativ auf die Performance auswirken kann.
Das bedeutet jedoch nicht, dass der reservierte Speicher mit *Blanks aufgefüllt wird.
Bei Feldern mit variabler Länge, wird die Länge aus den führenden Bytes ermittelt, ob und was im Anschluss daran steht ist irrelevant und wird auch in keiner Form initialisiert.

Ob man Options(*TRIM) verwendet oder nicht kommt auf die Anwendung an. In diesem Fall würde ich die Option setzen, aber nicht kategorisch ablehenen.

Birgitta

[rissling]

Ich fasse mal zusammen: :-D

• $string ucs2(5000) options(*trim);
  
  • Wird schon vom RDP nicht zugelassen:
    
    • RNF3379E: OPTONS(*TRIM) ist für den Parameter ungültig.
  
  
• $string ucs2(5000) options(*trim) const;
  
  • Geht zwar, aber der Parameter wird als Konstante übergeben, d.h. ich kann den geänderten Wert nicht zurück geben. Hilft mir also nicht.
  
  
• $string ucs2(5000) options(*varsize);
  
  • Die Länge der Variablen in der Funktion ist bei 5000 - es wird also das gesamte Feld übergeben. Bringt also nix.
  
  
• $string varchar(5000);
  
  • S.o. Länge 5000;
  
  
• $string varchar(5000) options(*varsize);
  
  • Compilerfehler:
    
    • RNF7535: Art und Attribut stimmen nicht mit dem Prototyp überein.

Ergo: ich lasse es so, wie es ist, denn so funktioniert es :-)

[Pikachu]

Nimm besser den %TRIMR() anstelle dem %TRIM().

Ich arbeite in der For-Schleife absichtlich mit Trim, da ich eine größere Menge Sätze bearbeite und das ganze spürbar langsamer wird, wenn man die gesamten 5000 Zeichen durchläuft, auch wenn evtl. nur 200 Zeichen belegt sind. So ist es wesentlich schneller und Leerzeichen am Anfang kommen bei mir nicht vor.

[BenderD]

... wieso wollt ihr da eigentlich mit Gewalt trimmen???
Das sauberste ist:

d cleanString     PR         65535    varying                       
d                                     EXTPROC('MYMOD_cleanString') 
d data                       65535    value                         
d                                     varying 

Procedure Interface entsprechend. Wenn die aufrufende Procdure korrekt arbeitet (im varying Feld zusammen bastelt, oder trimmed (wie es ihr schmeckt) passt alles, ein varying Feld weiß wie lang es ist!!!

Wer jetzt Angst vor Nano Sekunden hat, nimmt statt VALUE halt CONST, hoffentlich im vollen Bewusstsein, das CONST in Wirklichkeit hopefully CONST ist. (BTW: Performance entscheidet sich an anderen Stellen!)
Wer noch mehr Angst hat, nimmt Returntyp.
Bei ultimativen Angstzuständen nimmt man dann call by reference, muss dann aber sicherstellen, dass die Länge des Parameterstrings korrekt zurückgeht.

D*B

[Fuerchau]

Und wenn eben UCS2 dann "65535C" oder die Free-Alternative.
Und was hat die Übergabe mit dem Returnwert zu tun?
Die Übergabe als Parameter darf und soll ja auch nicht geändert werden.
CONST ist also durchaus erlaubt.
Vielleicht heißt es ja auch VARUCS2?

CONST und VALUE haben ja gerade den Vorteil, dass ich beliebige Parameter übergeben kann.
Also bei Dieters Beispiel:

D MyChar 20
D MyVarC 20 inz('ABC')

CleanString(MyChar) => Übergabe von 20 Zeichen (mit Längenangabe vorneweg)
CleanString(MyVarC) => *bergabe von 3 Zeichen (auch wenn max. 20 möglich wären)

Gerade das ist ja der Vorteil von varchar/varying.

[rissling]

Und wenn eben UCS2 dann "65535C" oder die Free-Alternative.
Und was hat die Übergabe mit dem Returnwert zu tun?
Die Übergabe als Parameter darf und soll ja auch nicht geändert werden.
CONST ist also durchaus erlaubt.
Vielleicht heißt es ja auch VARUCS2?

Ich wollte aber gerne den geänderten Wert des Unterprogramms wieder im Hauptprogramm nutzen - deshalb muss der Parameter sehr wohl geändert werden. Ich hätte natürlich die Variable auch Call-by-Reference übergeben können, wenn ich denn gewußt hätte, wie das geht.

CONST und VALUE haben ja gerade den Vorteil, dass ich beliebige Parameter übergeben kann.
Also bei Dieters Beispiel:

D MyChar 20
D MyVarC 20 inz('ABC')

CleanString(MyChar) => Übergabe von 20 Zeichen (mit Längenangabe vorneweg)
CleanString(MyVarC) => *bergabe von 3 Zeichen (auch wenn max. 20 möglich wären)

Gerade das ist ja der Vorteil von varchar/varying.

Die Übergabe lediglich der benutzen Zeichen des Strings hat ja nicht funktioniert, wie ich oben beschrieben habe. Daher muss ich den String im Unterprogramm auf jeden Fall trimmen, weil ich bei 3 Zeichen im String nicht 5000 Schleifendurchläufe machen möchte.