-941 when using UPPER or LOWER functions

IDS 11.70.FC6 and 12.1.FC3 when we're using the upper or lower functions we keep getting (somewhat randomly but quite constant) -941 errors saying that the function can't be evaluated. The data in the table is all a-z with _ and it seems like these are the only functions it's upset about. Anyone else ran into this?

We've removed the _ from the columns and that's not the problem either(on a whim and a hope)

On 08/04/14 15:21, NATE HICKS wrote: > IDS 11.70.FC6 and 12.1.FC3 > > when we're using the upper or lower functions we keep getting (somewhat > randomly but quite constant) -941 errors saying that the function can't be > evaluated. The data in the table is all a-z with _ and it seems like these are > the only functions it's upset about. Anyone else ran into this? > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > What DB_LOCALE are you using? and are you using GL_USEGLU? -- Ciao, Marco ______________________________________________________________________________ Marco Greco /UK /IBM Standard disclaimers apply! Structured Query Scripting Language http://www.4glworks.com/sqsl.htm 4glworks http://www.4glworks.com Informix on Linux http://www.4glworks.com/ifmxlinux.htm

DB_LOCALE=en_us.utf8GL_USEGLU=1 I guess the LOCALE might be the issue? if so is there a function that supports it?

On 08/04/14 15:37, NATE HICKS wrote: > DB_LOCALE=en_us.utf8> GL_USEGLU=1 > > I guess the LOCALE might be the issue? if so is there a function that supports > it? > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. Got it in one! if my suspicion is right, it might be GL_USEGLU -- Ciao, Marco ______________________________________________________________________________ Marco Greco /UK /IBM Standard disclaimers apply! Structured Query Scripting Language http://www.4glworks.com/sqsl.htm 4glworks http://www.4glworks.com Informix on Linux http://www.4glworks.com/ifmxlinux.htm

On 08/04/14 15:37, NATE HICKS wrote: > DB_LOCALE=en_us.utf8> GL_USEGLU=1 > > I guess the LOCALE might be the issue? if so is there a function that supports > it? Q - are the nchar columns involved larger than 512 bytes? -- Ciao, Marco ______________________________________________________________________________ Marco Greco /UK /IBM Standard disclaimers apply! Structured Query Scripting Language http://www.4glworks.com/sqsl.htm 4glworks http://www.4glworks.com Informix on Linux http://www.4glworks.com/ifmxlinux.htm

nothing larger than a varchar 64. going to try everything without the GL_USEGLU set though and see if that helps anything.

On 08/04/14 17:55, NATE HICKS wrote: > nothing larger than a varchar 64. going to try everything without the > GL_USEGLU set though and see if that helps anything. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > Then, just speculation, but me thinks you have combination of characters that ICU (International Components for Unicode, the library IDS uses when GL_USEGLU=1) thinks is invalid If I could have a test case, that would help me help you... -- Ciao, Marco ______________________________________________________________________________ Marco Greco /UK /IBM Standard disclaimers apply! Structured Query Scripting Language http://www.4glworks.com/sqsl.htm 4glworks http://www.4glworks.com Informix on Linux http://www.4glworks.com/ifmxlinux.htm

if I shut off useglu I get other errors. another thing it seems to only do it if our ESQL/C jobs are running. if they're not running Java and dbaccess both behave as expected.

If I unset GL_USEGLU I get other errors. It seems as though it's related to running a job we have in ESQL/C because when it's not running the functions work fine. Very strange.

What was the GLU setting when the code was compiled ? Paul Watson Oninit www.oninit.com +1 913 387 7529 On Apr 9, 2014, at 7:58, "NATE HICKS" <nathaniel.hicks@trnswrks.com> wrote: > If I unset GL_USEGLU I get other errors. It seems as though it's related t= o=20 > running a job we have in ESQL/C because when it's not running the function= s=20 > work fine. Very strange.=20 >=20 >=20 > **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20

when we compiled it with GL_USEGLU=1 the script didn't work right so we re-compiled it unset and the script works but everything else isn't happy about anything when it runs.

On 09/04/14 14:21, Paul Watson wrote: > What was the GLU setting when the code was compiled ? > The GLU library gets loaded dynamically, so the question is "what's the GLU setting in the esql/c application execution environment?"- but as I understand it, it's the engine that's throwing the -941 when executing a statement that has an UPPER / LOWER function somewhere, so that should not be relevant. Or, are you getting a -941 from a rupshift() / rdownshift() call inside the esql/c application? -- Ciao, Marco ______________________________________________________________________________ Marco Greco /UK /IBM Standard disclaimers apply! Structured Query Scripting Language http://www.4glworks.com/sqsl.htm 4glworks http://www.4glworks.com Informix on Linux http://www.4glworks.com/ifmxlinux.htm

@Mark Was just curious - been writing a lot of UDR code and see 'strange' errors i= f there is a mismatch between the compile and engine startup settings Cheers Paul Paul Watson Oninit www.oninit.com +1 913 387 7529 On Apr 9, 2014, at 8:37, "Marco Greco" <marco@4glworks.com> wrote: > On 09/04/14 14:21, Paul Watson wrote:=20 >> What was the GLU setting when the code was compiled ? >=20 > The GLU library gets loaded dynamically, so the question is "what's the GL= U=20 > setting in the esql/c application execution environment?"- but as I unders= tand=20 > it, it's the engine that's throwing the -941 when executing a statement th= at=20 > has an UPPER / LOWER function somewhere, so that should not be relevant.=20= > Or, are you getting a -941 from a rupshift() / rdownshift() call inside th= e=20 > esql/c application?=20 >=20 > --=20 > Ciao,=20 > Marco=20 > __________________________________________________________________________= ____=20 > Marco Greco /UK /IBM Standard disclaimers apply!=20 >=20 > Structured Query Scripting Language http://www.4glworks.com/sqsl.htm=20 > 4glworks http://www.4glworks.com=20 > Informix on Linux http://www.4glworks.com/ifmxlinux.htm=20 >=20 >=20 > **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20

On 09/04/14 14:47, Paul Watson wrote: > @Mark > > Was just curious - been writing a lot of UDR code and see 'strange' errors i= > f there is a mismatch between the compile and engine startup settings > > Cheers > Paul > Gets muddier and muddier... What's needed is the exact bit of esql/c that's failing... -- Ciao, Marco ______________________________________________________________________________ Marco Greco /UK /IBM Standard disclaimers apply! Structured Query Scripting Language http://www.4glworks.com/sqsl.htm 4glworks http://www.4glworks.com Informix on Linux http://www.4glworks.com/ifmxlinux.htm

Honestly I'm not sure. The strangest part to me is that it only happens(happens to everything) while this ESQL/C job is running. IBM is looking at it though I'll update when we've got a fix.

On 10/04/14 16:43, NATE HICKS wrote: > Honestly I'm not sure. The strangest part to me is that it only > happens(happens to everything) while this ESQL/C job is running. IBM is > looking at it though I'll update when we've got a fix. > Let's be clear on this - are you saying that if this esql/c session is running, the all other sessions get 941's? If this is the case, could you tell me the exact version of the engine that you are running (oninit -version: I need to see engine and GLS version and build date)? I believe you could be running into IC98327 -- Ciao, Marco ______________________________________________________________________________ Marco Greco /UK /IBM Standard disclaimers apply! Structured Query Scripting Language http://www.4glworks.com/sqsl.htm 4glworks http://www.4glworks.com Informix on Linux http://www.4glworks.com/ifmxlinux.htm

correct. if the job is running other sessions will get 941s. Java sessions dbaccess sessions a little bit of everything will begin to bomb. onstat -versionProgram Name: onstat Build Version: 12.10.FC3 Build Number: N204 Build Host: cxp01007 Build OS: AIX 6.1 Build Date: Thu Feb 27 22:22:02 CST 2014 Build Timestamp: 27-Feb-2014.21:30:00UTC-06 GLS Version: glslib-6.00.FC3

On 10/04/14 17:45, NATE HICKS wrote: > correct. if the job is running other sessions will get 941s. Java sessions > dbaccess sessions a little bit of everything will begin to bomb. > > onstat -version> Program Name: onstat > Build Version: 12.10.FC3 > Build Number: N204 > Build Host: cxp01007 > Build OS: AIX 6.1 > Build Date: Thu Feb 27 22:22:02 CST 2014 > Build Timestamp: 27-Feb-2014.21:30:00UTC-06 > GLS Version: glslib-6.00.FC3 Not IC98327 - already fixed in there Onmode -I 941 shown anything? Have you tried with previous versions, in particular 11.70.xC7 and below? -- Ciao, Marco ______________________________________________________________________________ Marco Greco /UK /IBM Standard disclaimers apply! Structured Query Scripting Language http://www.4glworks.com/sqsl.htm 4glworks http://www.4glworks.com Informix on Linux http://www.4glworks.com/ifmxlinux.htm