Modify jsonGetValue built in function to tolerate unknown and reordered name/values and objects in JSON text

This has been delivered via PTFs to the 6.1 compiler and to the runtime library. See APAR PH55298 / PTF UI92507 for more details

Team, could you please let us know ETA for the this change for JSONGETVALUE in PL/I program?

We are getting below error when missed to include any field names not declared in the structure

Error Message:
IBM0725S ONCODE=5065 Name in JSON source does not match that in the target. From compile unit M6API at entry point AGRE_ACCESS at compile unit offset +000017D2 at entry offset +00001542 at address 240018DA.

Agreed the RFE does contain two parts with the second part being more helpful:
1. Reordered name/values
2. Names not present in the structure

The ability to honor or ignore the NAME condition with a compiler option would offer flexibility for all customers.

As described, the RFE does contain two parts:
1. Reordered name/values
2. Names not present in the structure

The second part is probably the most beneficial as it allows additional names to be added by the service provider, allowing new functionality to be implemented in the API's that return the JSON being parsed in this PLI program. I believe (but cannot prove) that adding new names would be more common than reordering them. These new names could be added anywhere in the JSON text. Also, new objects or groups can be added as well.

As industry practice dictates, new names can be added to any JSON output at any time and should be tolerated by the calling application. Based on this, I believe that the Name condition should ignored by default. I can also see that having an option to Not ignore the unknown name might helpful to some customers. Hopefully this could be a compiler option and would not need to be handled by application code.

Elements of the structure can already be omitted, but any elements in the JSON text must (currently) be in the same order as in the structure. Changing that is one part of this RFE. Accepting elements in the JSON text that are not in the structure is a little more questionable. In GET DATA statements, this would cause the NAME condition to be raised, and maybe that would be the right thing to here? or maybe an option should specify whether they are simply ignored or a condition is raised? This second part of the RFE is probably easier, but is it more or less important than the first part?

Allowing for names in the JSON that are not present in the structure is definitely a step forward. Allowing names in any order would be the desired goal. We can do this using the COBOL JSON PARSE, however it would be best if our PLI developers do not have to call a COBOL program simply to parse their JSON.

Not really sure if this request would need to be a option since it would offer more flexibility and assuming it should not cause issues for existing code.

You can use the z/OS JSON parser in the z/OS client web enablement toolkit as an alternative to the built-in functions.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieac100/ieac1-cwe-json.htm

We agree that this would be useful, bit allowing elements in any order would require substantial redesign on our part - we need to evaluate that before committing to this. Allowing the JSON text to have name-value pairs that are not in the target structure would be (maybe much) easier - but it would probably have to be optional