JSON numeric/string conversion

Yes, a corresponding JSON GENERATE be implemented as well.

Thank you. Will a corresponding JSON GENERATE be implemented as well. In my use case we are sending a "number string" and it is being echoed back, so we really need both implemented for this to work out for us.

Hi, thanks for the update. We have decided to accept this RFE for JSON PARSE.

For JSON PARSE, we plan to accept the following string formats to be parsed to numeric COBOL data item (subject to change though):

1. The string must contain one or more integer digits.
2. The string may contain zero or more decimal digits.
3. The string may contain zero or one decimal point. If the number contains decimal digits a decimal point is required.
If the number does not contain decimal digits a decimal point is disallowed.
4. The string may be prepended with a dash "-" representing a negative value.

This RFE will be updated further once put into plan.

I just looked at my example and noticed my "result" was incorrect. I stated that MY-DOCUMENT would give the following result:
{amount: 100.00}
In fact what I am really wanting is this (and in RESULT-DOCUMENT (the output), not MY-DOCUMENT (which is the source):
{amount: "100.00"}

Sorry for the confusion!

The provided information is being assessed.

@fswarbrick

I undestood this rfe was for a string representation of a number, and more specificly a currency amount.

Do you consider numeric edited instead of pure numeric? How JSON GENERATE / JSON PARSE deal with numeric edited?

hi,

Look at https://www.json.org to see what is a valid json number :
- no trailing sign
- only negative leading sign, positive leading sign not accepted
- no leading zero, unless only one zero for integer part of number
- decimal mark is a point
- at less one digit after decimal mark, if fraction part is present
- optional leading sign for exposant part, if exposant part is present

A regex can validate a json number :

[-]?([1-9][0-9]*|0)(\.[0-9]+)?([Ee][+-]?[0-9]+)?

The simplest example would be something like the following:

01 MY-DOCUMENT.
05 amount PIC 9(11)V99.

MOVE 100.00 TO amount
JSON GENERATE REQUEST-DOCUMENT
FROM MY-DOCUMENT
NAME MY-DOCUMENT IS OMITTED
CONVERTING amount TO JSON STRING

*> MY-DOCUMENT = "{amount:100.00}"

MOVE REQUEST-DOCUMENT TO REPLY-DOCUMENT
MOVE SPACES TO MY-DOCUMENT

JSON PARSE REPLY-DOCUMENT
INTO MY-DOCUMENT
NAME MY-DOCUMENT IS OMITTED
CONVERTING amount FROM JSON STRING
*> amount = 0000000010000

I based the changes to the JSON statements based on how the CONVERTING phrase is currently implemented for boolean fields.

I tested our remote service and it accepted a leading '+' sign and a leading '-' sign (though the latter was rejected by additional logic within the service, to not allow a negative amount). A trailing sign indicator was rejected as invalid, as was an amount including comma separators. That being said, I would not be opposed to those being allowed as an option. Not sure how they would be specified, however. The simplest would be to not include them (only the decimal point).

Let me know if you need additional clarification.

Hi,

We are still evaluating this request. However, can you please provide a usage example of the different cases that you would need (eg: currency signs, +/- signs, . or , signs, euro signs, just digits etc)

Hi,

Could the use of edited digital zones meet this need?
If the COBOL zone is pure numeric, JSON parses and generate treats it as a numeric zone.
If the COBOL zone is edited numerically, JSON parses and generates treats it as a string.

Instead of "PIC 9(9)V99", which is pure numeric, so a number for JSON, declare "PIC Z(8)9.99", which is numeric edited, so a string for JSON.