Enhance Comms Stub to segment Data for CICS API Requestor services

The currently CALL interface in the zos Communication Stub is too rudimentary in nature and fails to take into account large and complex data structures now prevalent in many common external API's.

This constraint is a major blocker for effective exploitation in the API requestor element of the zos Connect EE product.

In effect Unbounded Arrays, combined with large data structures and optional data in SWAGGER file definitions result in bloated COBOL (and PL1) data structures. In some cases a JSON payload of 7k or 9k requires COBOL data structures of 10's of MB ! In turn these means that excessive EUDSA is allocated and in effect zos Connect EE delivers a solution which functionally may just work but from a non-functional perspective is deficient.

The remedy has to be to enhance the Comms Stub to deliver for CICS applications data segmented into separate CICS containers.

So deliver optional data into separate arrays with mandatory data placed into a specified container, e.g. DFHZOSCE-REQUEST / DFHZOSCE-RESPONSE.

Again this will allow CICS applications to allocate space and read / create data in a selective manner – and able to manage the EUDSA required.

Where data is already part of an UnBounded Array then place mandatory elements into numbered occurrences, e.g. DFHZOSCE-REQUEST-nn / DFHZOSCE-RESPONSE-nn.

Allow for Unbounded Arrays within Optional Data – and vica versa up to an agreed limit (suggest three for a starter). In order to allow for a considerable number of data structures in the ZCONBT tool generate separate directories for each service.