MVSFORUMS.com

eskaysem · Beginner Joined: 31 Mar 2003 Posts: 29 Topics: 13

Hello,
We have a case where when we parse the XML, we are getting a single content character being split into two. IN our case, specifically, parser was splitting 50000.00 as 50000 and .00

If you could throw some light on the issue, it would be great.

Thanks
Santosh
_________________
Thanks!,
Santosh Kulkarni

kolusu · Posted: Mon Oct 04, 2010 10:12 am Post subject:

eskaysem,

Is the receiving field defined with decimals? Look at the example here

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg10/1.13.3.2.6?

If that is not the case , then post detailed information on what you're trying to accomplish. Do not make people guess what you mean. This will give you a much better chance of getting a good answer to your question. You need to show us the piece of code which you think is causing the problem and a sample of input data.

Kolusu

eskaysem · Beginner Joined: 31 Mar 2003 Posts: 29 Topics: 13

Thanks kolusu for the reply. Sorry I should have been more specific about the scenario.
I got to know from our systems people that we recently upgraded from compat to xmlss on the parser side.

Now coming to the problem, yes, the destination field is X(12), so can handle decimals.
We had many a test cases working just fine, but this one. This one too, is having issues for this particular tab.

To be more specific, let me attach part of image for XML from spy.

It worked for all other tabs, but the highlighted one, that too on just one value - was parsing 50000.00 as 50000 and .00 and overwriting the same variable and ultimately failing the case.

Onto cobol side, we had XMLSS as our parser and we used standard statement -

kolusu · Posted: Tue Oct 05, 2010 10:53 am Post subject:

eskaysem,

Looking at the data , I am guessing that either you have a working storage table which is overflowing after 17 occurrences or one of the field is defined short (ex : coverage field) . You have no trouble parsing the 4th row with the same contents with the only change coming from coverage code. Check for these and see if you find a pattern. Just for sanity move this trouble record to the beginning of the file and see if parses correctly.

Kolusu

misi01 · Posted: Sat Oct 09, 2010 2:54 am Post subject:

Are you getting the same problem for row 4 which seems almost identical ? (Or are you simply referring to the actual column Limit1 which is failing)
_________________
Michael