Handling invalid and uninitialized application-supplied data

How to tolerate invalid data that is found during transformation between JSON and application data.

Service enabling an existing application results in CICS® becoming aware of the contents of the COMMAREA or containers that are used by that application. The WSBind file that is deployed to CICS contains information about the data format, including the names, location, and data type of each individual field. CICS uses this information to facilitate the transformation between the XML/JSON data representation, and the application data.

If the application data is not consistent with the information that is stored in the WSBind file, CICS reports a problem and fails to transform the data. For example, an application interface is changed but the WSBind file is not regenerated and redeployed. This type of problem often results in a DFHPI1010 error message.

A more subtle variant of this condition can occur in scenarios where the application has left fields that are deliberately uninitialized. For example, a signed packed decimal field might contain low values (null bytes). When CICS processes that field, it cannot determine that the invalid value is deliberately uninitialized. CICS displays the DFHPI1010 error message and the data transformation fails. Applications can leave fields uninitialized for many reasons. For example,

A language structure might describe both the input and output data formats, but the uninitialized field was for input only.
The application might detect an error, set a response code, and return without the other output fields initialized.
Conditional logic within the application might control whether the field is considered to be meaningful.

The ideal response to this scenario is for the application to be changed to ensure that no invalid values are passed to CICS for processing. An alternative option is to set the Assistant's DATA-SCREENING option to DISABLED at the time that the WSBind file is generated. This option causes CICS to tolerate bad application supplied values, and to replace such values with a default value, typically zero. These options can make service enablement of existing applications simpler, but makes error detection more difficult, and must be used with care. If data screening is disabled, it's more likely that application generated data errors is not detected by CICS.

A related condition can be experienced where application generated arrays are left partially unpopulated. For example, consider an array of 1000 records of data; the application might initialize the first 10 records. CICS generates an XML or JSON representation of the data and populates all 1000 fields, although 990 are empty. The ideal response to this problem is to introduce an OCCURS DEPENDING ON clause to the application to indicate precisely how many records are considered to be populated. An alternative is to use the TRUNCATE-NULL-ARRAYS option of the Assistants when the WSBind file is generated. This option instructs CICS to attempt to detect uninitialized data, and to truncate the array at that point. Use of this option can result in elegant JSON/XML data that is generated from ambiguous and uninitialized application data, but introduces the risk of accidental data loss if the array content is indistinguishable from uninitialized data.

The best solution is to have applications produce unambiguous data that is entirely consistent with the language structure that describes that data. Use of the TRUNCATE-NULL-ARRAYS=ENABLED and DATA-SCREENING=DISABLED options can cause CICS to tolerate imperfect application-supplied data, but they introduce an element of risk and uncertainty in the process.

The following example demonstrates how to use these options.