Re: Sprintf and decimal point -- C400-L

Hi Bruce,

I'm in Italy and the locale IT appears to be right.
But I think that "someone" installed some software
that changed the current "LANG" to "lang" and replaced
LANG with Norvegian locale (!!)

Btw the problem for me occurred with tiff2pdf, a
program that - with libliff - I ported in ileC a few
years ago. This writes out some pdf tags (using
sprintf) where numbers are floats that - according to
pdf rules - must be edited with period and not commas.
It worked fine since a couple of months ago.

Now instead of changing the locale I amended the code
using the setlocale() with US and recompiled with *CLD
option, and now it seems to work again.

Thanks for your clear explanation.
Giuseppe.
--- Bruce Vining <bvining@xxxxxxxxxxxxxxx> ha scritto:

I think it's premature to recommend a solution. My
concern is that "someone" has set up this job with
two locales -- neither of which use the period as a
decimal point. IT_IT_E (Italian with Euro support)
specifies that a space be used for the decimal point
while NO_NO (Norwegian) specifies that a comma be
used for the decimal point.

This leads me to ask "who" is complaining about
the comma being used?

If the end user, then most end users I've met
would be very upset if some of their applications
used a comma and some used a period (they usually
want a consistent representation). Which do they
want? If they want "everything" Norwegian EXCEPT
the decimal point then I would create a new
(customized) locale for them and associate that
locale with the job. The source for all of the IBM
provided locales can be found in
QSYSLOCALE/QLOCALESRC with the member name matching
the locale name. To create your own locale I would
copy the IBM source to another source file (and
another member name), modify the decimal point
definition, create a new locale using the CRTLOCALE
command, and then associate that locale with the
user.

If it's the application programmer complaining
because they are parsing the buffer returned by
sprintf() for a hardcoded period, then I would say
"too bad". They are trying to run a
non-internationalized application in an
international environment -- fix the program and
don't modify the user environment to accomodate the
developer. The current value for the decimal point
(and many, many, many other national language
settings) can be found easily with the
QlgRetrieveLocaleInformation API. Set the precedent
now to retrieve the user preferred decimal format
and use that when scanning the buffer. It's much
better to do it right from the start :)

I hope this helps,
Bruce Vining
Bruce Vining Services

beppecosta <beppecosta@xxxxxxxxxxx> wrote:
Hi Bruce,

At present, WRKENVVAR shows two variables:

lang = '/QSYS.LIB/IT_IT_E.LOCALE'
LANG = '/QSYS.LIB/NO_NO.LOCALE'

I think I should change the uppercase one.

Is there a way to code it in the program, without
impacting the other programs that maybe run in the
job
?

Thanks-
Giuseppe.

--- Bruce Vining ha scritto:

The sprintf() API is locale sensitive so what you
need to do is specify a locale that uses the

period

as a decimal point. One quick way to do that is to
WRKENVVAR and change the job level environment
variable LANG from whatever it currently is to
"/QSYS.LIB/EN_US.LOCALE". Assuming you haven't
modified this IBM supplied locale, running your
program should now show the period being used for
the formatting of doubles.

There are many, many other ways to specify a
locale. This is simply one quick and easy way.
Note that this change may also impact the running

of

several other C library functions that are locale
sensitive.

Hope this helps,
Bruce
Bruce Vining Services

beppecosta wrote:
I have a C program that prints a float with
sprintf.

The decimal point is comma. How can I have the

point

separator instead ?

I have tried to compile with TGTCCSID(37), to
compile
from a job with CCSID(37) but it still prints with

a

comma.

Thanks.

___________________________________
L'email della prossima generazione? Puoi averla

con

la nuova Yahoo! Mail:
http://it.docs.yahoo.com/nowyoucan.html
--
This is the C programming iSeries / AS400 (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at http://archive.midrange.com/c400-l.

Bruce
Bruce Vining Services
507-206-4178
--
This is the C programming iSeries / AS400 (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at http://archive.midrange.com/c400-l.

___________________________________
L'email della prossima generazione? Puoi averla con
la nuova Yahoo! Mail:
http://it.docs.yahoo.com/nowyoucan.html
--
This is the C programming iSeries / AS400 (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at http://archive.midrange.com/c400-l.

Bruce
Bruce Vining Services
507-206-4178
--
This is the C programming iSeries / AS400 (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at http://archive.midrange.com/c400-l.

___________________________________
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html