× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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>>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.