[freetds] Running FreeTDS under VMS

James K. Lowden jklowden at schemamania.org
Fri May 2 02:41:33 EDT 2003


On Thu, 1 May 2003 23:45:37 -0500, "Craig A. Berry" <craigberry at mac.com>
wrote:
> At 5:11 PM -0400 5/1/03, Lowden, James K wrote:
> 
> >What are you supposed to do in a pure VMS system, if you can't pass the
> >output of nl_langinfo(CODESET) to iconv? 
> 
> Good question.  It is rather discouraging that -- at least as far as I
> can find -- none of the standards defining nl_langinfo makes any
> reference to iconv or vice versa.  The only somewhat official statement
> I can find about the relationship between the two comes from the Common
> Desktop Environment (CDE) documentation to iconv_open() and says:
> 
> "Note that while the nl_langinfo (CODESET) function may be used to
> obtain the code set associated with the current locale, it is
> implementation dependent whether any conversion names match the return
> from the nl_langinfo (CODESET) function."

Doncha love those guys?  I hope you'll forgive a short rant.  

Whenever any corporate spokesman says "we believe" something, he really
means "we don't believe, but we'd like you to believe".  The 1980s was a
time when "Open" was (putatively) adopted everywhere and existed nowhere. 
Everything but everything that was "open" then is dead now, because you
can't make something open by changing its name.  (Are you listening,
Digital?)  We are left to deal with the detritus of their noncollaborative
process: failed organizations, toothless amorphous hulking standards. 
Proprietary firms had their own form of "embrace and extend", and part of
their reason for participating in "open" fora was to prevent the standard
from intruding on their perceived competitive advantage.  They succeeded,
only too well.  

Thank you.  

> Which kind of makes you wonder what's the point of having nl_langinfo if
> it isn't guaranteed to give you something you can use.

Right, well, the standards certainly won't force internal consistency.  
:-/

> Another piece of the puzzle may be if ASCII is considered stateful;
> there are various shifts involved in defining what upper ASCII means. 
> iconv, at least according to some vendor docs, only does stateless
> conversions, though that may be implementation dependent as well.  This
> part I don't understand very well and may be a red herring.

>From everything I've seen, btw, "ASCII", unqualified, is 7-bit, the common
name for ISO 646.  Anything based on ASCII using the eighth bit is "8-bit"
or "extended" ASCII, the most common of which is Latin1, ISO-8859-1.  At
any rate, that's how I use the term, just to avoid confusion.  

http://czyborra.com/charsets/codepages.html#CP932

might be interesting to you. The only stateful codesets I'm aware of are
CJK.  Certainly none of the ISO-8859 family has that problem, nor does any
form of Unicode.  I plan to handle Asian data with UTF-8 and (eventually)
UCS-2.  GNU iconv deals with the ugly alternatives, but I'm hoping we
won't have to bother, because UTF-8 is happening.  It's just not an
important problem now, and might well never be.  

> >I can see writing a trivial tds_get_iconv_ascii_name() that returned
> >the appropriate string in the absence of locale_charset(). 
> 
> That sounds reasonable.

And necessary, it would seem.  :-/

Regards, 

--jkl



More information about the FreeTDS mailing list