Discover Informix Event - September 16, San Jose, California

I'm sure most everyone on this list got this e-mail turd dropped in their in box.

Now the reason I call this a turd is because it contains the following:
"Find out what's new, and why the Informix fan base has voted IBM Informix the #1 vendor at VendorRate for two years in a row"

Silly me. VendorRate no longer exits.
(www.vendorrate.com is currently parked at GoDaddy)
http://www.vendorrate.com/

Now for those Informix/IBM apologists who will say "Gumby you idiot, you got the site wrong..."
All I can say is the following:
"LOS GATOS, Calif.--(BUSINESS WIRE)--VendorRate (www.vendorrate.com),
the only Web-based business information service that offers quick,
confidential performance ratings and comparisons of technology vendors,
announced today that IBM Informix, ChemSW, and 10ZiG Technology were the
top rated vendors for overall customer satisfaction in 2009."
Taken from :http://www.businesswire.com/news/hom...emSW-10ZiG-Top

And of course this missive posted here already...
http://www.eggheadcafe.com/software/...-any-more.aspx


So, lets ask ourselves just how reliable and trustworthy a 'vote' by the 'Informix loyalists' who filled out a survey on a site that no longer exists?

Hmmm. If I were a C level executive at a mid to large size company. I'd just shrug my shoulders and say "Informix who?"

I guess no one bothered to proof the garbage being sent via the IIUG (er IBM's marketing shill of Informix since IBM can't market a single product that doesn't say DB2 ;-)

A special note to Steve Mills... With Moffat out of the front running, are you next, or do you plan to retire when Sam does so that you can avoid the shite?

And a special shout out to Jerry K. Too little, Too late. You have had ample time to pay attention, yet you were too busy looking elsewhere.

So when are you going to release a blade that will allow Hadoop to pull data directly from Informix? Not that anyone but Wal*Mart would want it, andof course you can talk to Mike O. formerly of Illustra/Informix, now of Cloudera. He may know something about Wal*Mart's inquiry in to the world ofHadoop. ;-)

But hey! What do I know? Maybe just enough to ask the *right* questions? ;-)

-G

Funny you should mention IBM's Hadoop story.
It sucks. No offense to those who are forced to sell it and work in it, but giving away a brain dead, dead on arrival, aborted creation of the damned, is less than worthless.
32bit Linux only? (No one runs a serious cluster on 32bit Linux. IBM's JVM?They all run on Sun's ... er Oracle's JVM (pre 18 release or post 20 release).
And they turn to Cloudera (the *only* commercial support company) for support.

Again, IBM sticking their little toe in the waters... I wouldn't trust them to deliver a solution to anyone.

So one has to ask ... if you weren't running IDS, which database would *you* choose?

-G

Can someone tell me how does this LANG parameter behaves and what is the
impact?
For example :
LANG=C versus LANG=en_US
After migrating to IDS11.FC6.W2 from 7.31.UD8 on AIX 5.3 and CSDK.3.5 on
the windows desktop in one server the users are receiving the following
error code -23197 and they cannot connect to the database.

-23197


Database locale information mismatch.


The locale information GL_CTYPE or GL_COLLATE in the system catalog of the
specified database does not match the locale information in the specified
environment variable DB_LOCALE. Check the value of DB_LOCALE


Those two are set to en_US.CP1252 but on the database server query of
systables show


"select tabname, site from systables where tabname like ' GL%';
tabname GL_COLLATE
site en_US.819
tabname GL_CTYPE
site en_US.819


Changing the value of CLIENT_LOCALE = EN_US.8859-1 of my laptop worksbut
not taking a chance that late in the ball game to make this change in all
the desktops without further testing so I revert back to IDS7.


Interestingly, we compared all servers where users are able to connect
versus the one that is not working and we found one discrepancy.


Server where it does not work!
$ locale
LANG=C
LC_COLLATE="C"
LC_CTYPE="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_MESSAGES="C"
LC_ALL=

Sever where it works

$ locale
LANG=en_US
LC_COLLATE="en_US"
LC_CTYPE="en_US"
LC_MONETARY="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_MESSAGES="en_US"
LC_ALL=

By the way both settings work in 7.31.UD8. Is LANG set to C on the OS the
reason why people can't connect to that one server. Informix install was
most likely done with that same setting of LANG on that server, what isthe
impact.

By reviewing the installshield wizard of IDS11, it is said that
If using a locale/language other than the default
Set $CLIENT_LOCALE
Set $DB_LOCALE
Set $SERVER_LOCALE
Set $DBLANG

Note: testing connection with ODBC driver via MS Excel Spreadsheet works
fine with both settings.

Any insights would be greatly appreciated!

Thanks in advance!

jp

On 06-09-2010 1:59, jpierrot (AT) chubb (DOT) com wrote:

Error 23197 means your database DB_LOCALE is set to one value and that
the client is using another. In older versions of the client software,
if you did not specify it, it would use the windows default (CP1252).
Also on older versions of the server side software that would work even
if you had en_us.819 on the server side. This was wrong.

IDS 11 (it started in late 9.40 fixpacks and not so late - xC5 maybe -
fixpacks of 10) the engine will not allow connections to the database
with different locale.

Since CSDK 2.90.TC6 (I may be missing the fixpack by 1 or 2...) the
client will ask the database which DB_LOCALE it uses if you don't
specify it.

LANG should be irrelevant for this AFAIK... Which make your observations
a bit weird, since you explicitly state that it make s a difference. I
would suggest you open a PMR with this. Tech support will be more than
happy to guide you through this.

This points to that the DB_LOCALE is en_us.819 which is the default for
Unix systems...

The problem is more on the client than on the server. Are your clients
all on CSDK 3.50?

Version 7 was permissive to this issue. Which in turn created a BIG
problem for some cusotmers... Basically, they ended up with a settings
on the client side where DB_LOCALE=CP1252 and CLIENT_LOCALE=CP1252, and
a server side configuration where DB_LOCALE=en_us.819. That means that
the customer were able to insert characters from the CP1252 codeset into
a database using 819. And because programs like MS word love to change
some characters (quotes, dash...) by CP1252 only codes, it can bring
more problems in the future.

Finally, there is an undocumented variable that can instruct the engine
to behave like it used to (wrong). I would not recommend it's use unless
you don't have other options...

Regards.

Just curious, what is that undocumented variable?

jp



From: Fernando Nunes <domusonline (AT) gmail (DOT) com>

To: informix-list (AT) iiug (DOT) org

Date: 09/06/2010 05:25 AM

Subject: Re: Issues with IDS11 migration

Sent by: informix-list-bounces (AT) iiug (DOT) org






On 06-09-2010 1:59, jpierrot (AT) chubb (DOT) com wrote:

Error 23197 means your database DB_LOCALE is set to one value and that
the client is using another. In older versions of the client software,
if you did not specify it, it would use the windows default (CP1252).
Also on older versions of the server side software that would work even
if you had en_us.819 on the server side. This was wrong.

IDS 11 (it started in late 9.40 fixpacks and not so late - xC5 maybe -
fixpacks of 10) the engine will not allow connections to the database
with different locale.

Since CSDK 2.90.TC6 (I may be missing the fixpack by 1 or 2...) the
client will ask the database which DB_LOCALE it uses if you don't
specify it.

LANG should be irrelevant for this AFAIK... Which make your observations
a bit weird, since you explicitly state that it make s a difference. I
would suggest you open a PMR with this. Tech support will be more than
happy to guide you through this.

This points to that the DB_LOCALE is en_us.819 which is the default for
Unix systems...

The problem is more on the client than on the server. Are your clients
all on CSDK 3.50?

Version 7 was permissive to this issue. Which in turn created a BIG
problem for some cusotmers... Basically, they ended up with a settings
on the client side where DB_LOCALE=CP1252 and CLIENT_LOCALE=CP1252,and
a server side configuration where DB_LOCALE=en_us.819. That means that
the customer were able to insert characters from the CP1252 codeset into
a database using 819. And because programs like MS word love to change
some characters (quotes, dash...) by CP1252 only codes, it can bring
more problems in the future.

Finally, there is an undocumented variable that can instruct the engine
to behave like it used to (wrong). I would not recommend it's use unless
you don't have other options...

Regards.
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list

Hmmm.... I believe that would make it "documented"
But no problem. It's already mentioned in Guy Bowerman's blog:

http://www.ibm.com/developerworks/bl...e_with_locales

It's called *IFMX_UNDOC_B168163* and you need to set it to 1 on the engine
environment and then restart it.

Regards.


On Mon, Sep 6, 2010 at 10:39 AM, <jpierrot (AT) chubb (DOT) com> wrote:


--
Fernando Nunes
Portugal

http://informix-technology.blogspot.com
My email works... but I don't check it frequently...

By the way, I have about 8 more instances on IDS11.FC6 and connectivity is
not an issue under the same conditions. But the connection is only withone
server but the only difference I can find between the two Unix machinesis

$ locale
LANG=C
LC_COLLATE="C"
LC_CTYPE="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_MESSAGES="C"
LC_ALL=

Versus :

$ locale
LANG=en_US
LC_COLLATE="en_US"
LC_CTYPE="en_US"
LC_MONETARY="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_MESSAGES="en_US"
LC_ALL=



From: Fernando Nunes <domusonline (AT) gmail (DOT) com>

To: informix-list (AT) iiug (DOT) org

Date: 09/06/2010 05:25 AM

Subject: Re: Issues with IDS11 migration

Sent by: informix-list-bounces (AT) iiug (DOT) org






On 06-09-2010 1:59, jpierrot (AT) chubb (DOT) com wrote:

Error 23197 means your database DB_LOCALE is set to one value and that
the client is using another. In older versions of the client software,
if you did not specify it, it would use the windows default (CP1252).
Also on older versions of the server side software that would work even
if you had en_us.819 on the server side. This was wrong.

IDS 11 (it started in late 9.40 fixpacks and not so late - xC5 maybe -
fixpacks of 10) the engine will not allow connections to the database
with different locale.

Since CSDK 2.90.TC6 (I may be missing the fixpack by 1 or 2...) the
client will ask the database which DB_LOCALE it uses if you don't
specify it.

LANG should be irrelevant for this AFAIK... Which make your observations
a bit weird, since you explicitly state that it make s a difference. I
would suggest you open a PMR with this. Tech support will be more than
happy to guide you through this.

This points to that the DB_LOCALE is en_us.819 which is the default for
Unix systems...

The problem is more on the client than on the server. Are your clients
all on CSDK 3.50?

Version 7 was permissive to this issue. Which in turn created a BIG
problem for some cusotmers... Basically, they ended up with a settings
on the client side where DB_LOCALE=CP1252 and CLIENT_LOCALE=CP1252,and
a server side configuration where DB_LOCALE=en_us.819. That means that
the customer were able to insert characters from the CP1252 codeset into
a database using 819. And because programs like MS word love to change
some characters (quotes, dash...) by CP1252 only codes, it can bring
more problems in the future.

Finally, there is an undocumented variable that can instruct the engine
to behave like it used to (wrong). I would not recommend it's use unless
you don't have other options...

Regards.
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list

Can someone tell me how does this LANG parameter behaves and what is the
impact?
For example :
LANG=C versus LANG=en_US
After migrating to IDS11.FC6.W2 from 7.31.UD8 on AIX 5.3 and CSDK.3.5 on
the windows desktop in one server the users are receiving the following
error code -23197 and they cannot connect to the database.

-23197


Database locale information mismatch.


The locale information GL_CTYPE or GL_COLLATE in the system catalog of the
specified database does not match the locale information in the specified
environment variable DB_LOCALE. Check the value of DB_LOCALE


Those two are set to en_US.CP1252 but on the database server query of
systables show


"select tabname, site from systables where tabname like ' GL%';
tabname GL_COLLATE
site en_US.819
tabname GL_CTYPE
site en_US.819


Changing the value of CLIENT_LOCALE = EN_US.8859-1 of my laptop worksbut
not taking a chance that late in the ball game to make this change in all
the desktops without further testing so I revert back to IDS7.


Interestingly, we compared all servers where users are able to connect
versus the one that is not working and we found one discrepancy.


Server where it does not work!
$ locale
LANG=C
LC_COLLATE="C"
LC_CTYPE="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_MESSAGES="C"
LC_ALL=

Sever where it works

$ locale
LANG=en_US
LC_COLLATE="en_US"
LC_CTYPE="en_US"
LC_MONETARY="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_MESSAGES="en_US"
LC_ALL=

By the way both settings work in 7.31.UD8. Is LANG set to C on the OS the
reason why people can't connect to that one server. Informix install was
most likely done with that same setting of LANG on that server, what isthe
impact.

By reviewing the installshield wizard of IDS11, it is said that
If using a locale/language other than the default
Set $CLIENT_LOCALE
Set $DB_LOCALE
Set $SERVER_LOCALE
Set $DBLANG

Note: testing connection with ODBC driver via MS Excel Spreadsheet works
fine with both settings.

Any insights would be greatly appreciated!

Thanks in advance!

jp