The following APAR is closed UR1 [Fixed in a future release]. Its
description seems to match closely with the effect described; albeit
Norwegian vs German, though I do not know the decimal separator for
those Locales. Refer to the circumventions. If by testing, those
actions each\separately resolves the issue, then presumably the issue is
or will be corrected in a later release. Unfortunately, the
maintenance\update of the /fixed-in release/ details of APARs that had
been closed UR1, is seriously lacking... thus likely, only a
service\support inquiry would reveal whether or at what release into
which a fix was eventually included. The APAR specifies the /planned/
fixed-in version was unspecified the last time the APAR was updated in
2007; i.e. v9r9m9 is included in the affected releases.
http://www.ibm.com/support/docview.wss?uid=nas230836cfcff647f27862572cb003c7815
APAR SE28757 RUN-THREADS-INCORROUT NUMVAL NOT WORKING WITH DECIMAL POINT
BUT DEPENDS ON LOCALE
"...
_Error Description_
In an ILE Cobol, without DECIMAL-POINT is COMMA clause, the intrinsic
function, NUMVAL, will not interpret a decimal-point correct but is
looking for a comma depending on the Locale that is used.
This failure is dependent on the Activation Group (ACTGRP) that is used.
One way to make it constantly fail is to use XML PARSE somewhere in the
program:
...
With an English Locale(EN_US) this works fine and outputs:
00000000001234567
With a German Locale(DE_DE) the output is:
00000000001234500
According to the ILE Cobol Reference, NUMVAL should only
depend on the presence or absence of DECIMAL-POINT is COMMA.
Problem Summary
***************************************************************
* USERS AFFECTED: User's using the NUMVAL or NUMVAL-C *
* intrinsic function with a locale that *
* does not use a "." for a decimal point *
* could see this problem when running their *
* program. The German locale is an example *
* of a locale that can see this problem. *
***************************************************************
* PROBLEM DESCRIPTION: Programs using the NUMVAL or NUMVAL-C *
* intrinsic function with a locale that *
* does not use a "." for a decimal *
* point can find that digits following *
* the decimal point do not appear in *
* the result. *
***************************************************************
* RECOMMENDATION: *
***************************************************************
Programs using the NUMVAL or NUMVAL-C intrinsic function with a locale
that does not use a "." for a decimal point can find that digits
following the decimal point do not appear in the result.
...
Circumvention
Use one of the following 2 circumventions:
1. Switch to an english Locale before using NUMVAL, then
switch back to the default locale eg:
SPECIAL-NAMES.
LOCALE "EN_US" IS ENG.
then
SET LOCALE LC_NUMERIC FROM ENG.
COMPUTE NUMNUM = FUNCTION NUMVAL (NUMSTRING)
SET LOCALE LC_NUMERIC FROM DEFAULT.
or
2. Use PROCESS FULLEXTEND3
..."
Regards, Chuck
On 12 Oct 2013 01:47, geir.kildal@xxxxxxxxxx wrote:
I'm almost getting it working.
The generation of XML works fine.
The parsing works mostly fine.
However, I do have a problem with numeric values containing
decimals; '325.25' ends up like 325.00 in the receiving field
when I use:
compute NUMFIELD = function numval-c(XML-TEXT)
NUMFIELD is pic 9(5)v99.
Am I using the wrong function? It works ok with numeric fields
without decimals.
Vries, Frans de on Friday, October 11, 2013 9:36 AM wrote:
Yes, there is... in ILE Cobol there are two statements, one for
generating and one for parsing:
Xml generate xmlPO from purchaseOrder count in numChars
XML PARSE FILE-STREAM xml-id PROCESSING PROCEDURE xml-handler
ON EXCEPTION
display 'XML document error ' XML-CODE
NOT ON EXCEPTION
display 'XML document successfully parsed'
END-XML.
<<SNIP>>
midrange.com
