JSON PARSE error handling improvements

JSON PARSE error handling improvements - Expose messages and tokens to application code.

It would be helpful if application logic can determine which PARSE messages to display or suppress. Also, message tokens can be useful in error handling in application logic. Providing the messages and tokens to the application can enable applications to code better solutions around error handling of PARSE conditions.

The WITH DETAIL phrase provides too much detail; ALL Parse messages appear in LEMSG. Many of these are expected conditions in some situations and we would like to suppress them (eg. IGZ0324I JSON array with name JSON-name at offset offset had fewer elements than the matching table item). Displaying all of these messages in job output can be distracting when diagnosing problems.

When WITH DETAIL is omitted not enough detail is provided; the only indication in the application code is JSON-STATUS and JSON-CODE. These do not provide details such as offset and other message tokens. The messages the application can display are missing these details which causes difficulty in diagnosing problems.

An alternative is needed to suppress LEMSG Parse messages, while also providing the necessary detail back to the application code.

Possible solution might be:

WITH DETAIL TO <data-name>

Where <data-name> might be a special register or a user define storage area (declared according to specification)

Additionally, <data-name> could reference a FILE that is open for output. This is less useful, however some customers might find it useful as an option since LEMSG contains more than parse messages.

This would redirect all JSON PARSE messages to program storage instead of LEMSG. The application code could then determine which messages to display or suppress.

Minimum details needed:

01 MY-JSON-MSG-TBL OCCURS UNBOUNDED DEPENDING ON JSON-MSG-CNT.

*> JSON-MSG-CNT is probably a special register

05 JSON-MSG-ID PIC X(08). *> ex. IGZ0324I

05 JSON-MSG-TXT PIC X(1024). *> Complete text that would be shown in LEMSG

05 JSON-OFFSET PIC 9(9). *> MOST IMPORTANT TOKEN

Possible other details (implement as much as possible). Parsing message text for details is risky since message text can change. Externalizing the token details in explicit variables is helpful.

05 JSON-MSG-TOKENS OCCURS 10 TIMES.

10 JSON-MSG-TOKEN-NAME PIC X(25).

*> ex. JSON-name / JSON-token-found /JSON-tokens-expected

10 JSON-MSG-TOKEN PIC X(25).

10 FILLER REDEFINES JSON-MSG-TOKEN.

15 FILLER PIC X(16).

15 JSON-MSG-TOKEN-NUMERIC PIC Z(8)9.