Problem mit QMQueries nach Umst. auf V6R1

[hartmuth]

Hallo

Nach Umstellg. auf V6R1 kommt bei einigen der gerne verwendeten QMQueries eine Fehler-Meldung, die ich im Internet nicht gefunden habe.
Meldung lautet:

EXACT_MATCH SHOULD NEVER BE OFF HERE

Konnte bisher nicht feststellen nach welcher Gesetzmäßigkeit dies erfolgt.
Da Programme täglich verwendet werden, habe ich natürlich ein Problem.

Danke für Hilfe

[Fuerchau]

Ein SQL-Beispiel wäre da nicht schlecht, so ist das stochern im Nebel.

[hartmuth]

Hallo

Hatte gehofft, die Meldung würde aussagen worum es geht.

Ich verwende UDFs
Das besagte (mittlerweile sind schon mehrere betroffene festgestellt) lautet z.B.:

SELECT
'AU' ART, AUF#, 0 VAR#, GETNEWPOSN() POS40,
0 UPOS1, 0 UPOS2, KDNR,
'PRDGRP' POSART,

' ' PROD, ' ' MAT, ' ' OBFL, ' ' IDNR, ' ' PRDBEZ,
7556 ARBGNR , 01 AGGRP,
GETSUMMNG() BSMNG, GETSUMMNG() OFMNG, 'm²' MEH,
TERMWOCH, TERMJAHR
FROM QTEMP/AUFPOSXMLP
WHERE STONESSRC/GETDSPN230(KDNR) LIKE '%Manzenreiter%'
FETCH FIRST 1 ROWS ONLY

[hartmuth]

Es scheint damit zu tun zu haben, dass es immer dann Probleme gibt, wenn UDFs verwendet werden.
Und die gibt es bei mir in fast allen QMQries...

[hartmuth]

Hallo, nochmals

Ich habe versucht, eines der beanstandeten QMQueries neu umzuwandeln.
Bei der Anweisung
...
VERTRBEREICH
FROM STEINE_DAT.AUFKPFP WHERE
AUF#=I_AUF# AND VAR#=0
;

wird beanstandet, dass die Variablen
AUF# und VAR# (wohlgemerkt sind das nicht die übergebenen, sondern jene der Tabelle) nicht definiert oder nicht verwendbar seien.

Was hat sich hier geändert mit V6R1 , für mich ergibt das fürs erste keinen Sinn.

[Pikachu]

Vielleicht ein Problem mit den # im Namen?

[hartmuth]

Daran habe ich auch schon gedacht. Mittlerweile hat sich in langen "Experimenten" gezeigt, dass die umstrittene Anweisung in einer anderen Datei keine Probleme verursacht.
Die Fehlermeldung ist also schlicht irreführend, das Problem liegt "tiefer". Fatal, jetzt weiß ich nicht mehr weiter.

[Fuerchau]

Da das #-Zeichen CCSID-abhängig ist, kommt es nun auf die CCSID des Systems (QCCSID), die installierte Stammsprache (Deutsch 2929) und die CCSID zur Laufzeit (des Jobs) an.

Beim Restore der Dateien kann es hier auch zu Problemen mit den Feldnamen kommen, wenn die CCSID beim Restore nicht die Selbe ist wie beim Save.

Ich denke mal, der Systemwert steht hier noch falsch (65535), so dass das #-Zeichen nicht richtig umgesetzt bzw. erkannt wird.

Gerade bei SQL ist bei der Verwendung dieser Zeichen mit Vorsicht zu arbeiten.

Ggf. stimmt ja die CCSID, dann ist allerdings der Syntaxchecker jetzt intolleranter und die Feldnamen müssen in Anführungszeichen gesetzt werden!
Aber Auchtung, in diesem Fall sind de Zeichen casesensitiv, also alle in Großbuchstaben zu setzen.

[hartmuth]

Das Problem hatte mit den UDFs an sich gar nichts zu tun, obgleich die Fehler-Meldung fatalerweise dies vermuten ließ. Es lag am Einspielen der Daten. Die Referenzen wurden doppelt angelegt, PTF SI44714 leider nicht genutzt.

Die Sache ist damit erledigt. Danke allen, die sich möglicherweise den Kopf zerbrochen haben.