Support for plain text data in z/OS Connect EE

Thank you for the information.

In summary:
- The primary use case backing this requirement is for "Prometheus to support monitoring of z/OS applications"
- z/OS Connect EE is for API enabling business applications and so this use case is beyond it's primary scope.
- If you were primarily using IBM Monitoring solutions we could have transferred the RFE to the most appropriate IBM team to assess (for instance there are some routes to Prometheus today through Omegamon products: https://github.com/rafal-szypulka/itm_exporter)
- However, as you are using BMC and Dynatrace, the only remaining course of action is for us to decline this RFE at this time and for you to pursue the requirement with your monitoring vendor of choice.

Thank you again for your engagement and time in helping us understand your requirement.

We are using BMC MainView and for message monitoring also IBM System Automation. This specific customer has also started to use Dynatrace on the mainframe, but Dynatrace currently doesn't support any kind of IMS batch application and the main focus of the customer on Dynatrace currently is performance optimization, which is only one topic in the whole monitoring scope.

Thanks for the additional information.

From talking to my colleagues in the Z Manage team, there may already be a route to use Prometheus to monitor z/OS applications, depending on which monitoring solutions you and your customers use today.

If you could list the key monitoring products (IBM and 3rd party) that you have, we would be able to advise what may be available to you today to meet this requirement.

I asked the customer I created this RFE regarding other examples but they only responded me, that currently only Prometheus is relevant for them. So we may wait for your colleagues on what they will come up with regarding Prometheus. I am still skeptic regarding such a solution. It probably won't work for the customer's use case, if this can't be extended somehow by them, because traditional mainframe monitoring solutions aren't able to get enough insight into these 24x7 running BMPs. Nevertheless I am pretty sure that they also would like to use Prometheus for normal monitoring use cases like IMS transactions coming into the system through z/OS Connect EE and MQ, if it won't require another expensive product license.

Thank you for the information.

It would be very helpful if you could provide a list of examples of "distributed software products supporting HTTP but not supporting JSON". This will enable us to gauge the pervasiveness of the market need.

In the meantime, since the Prometheus use case is firmly in the monitoring domain (rather than that of business APIs) we have contacted our colleagues in the Z Manage team to understand how best to approach this requirement (since the overall goal here is to be able to use Prometheus to monitor z/OS Applications). We hope to get response to you shortly on this matter that indicates to you how best to proceed.

The reason for a plain text option in general is not that this would make an API more consumeable (even though it would make sense to use plain text in JSON for some use cases like for instance z/OSMF does with it's dataset and job API). It is just because otherwise distributed software products supporting HTTP but not supporting JSON cannot directly send requests to z/OS Connect EE or cannot directly receive responses from z/OS Connect EE. An intermediate layer would need to be created just to convert plain text JSON and vice versa. Being forced to add such a layer increases efforts, error-proness and round trip times without adding any value.

Regarding the customer's Prometheus use case I can't find that CDP or Z APM Connect could be a solution to this. Neither I can find a statement clearly telling, that these products are able so send metrics in the format Prometheus expects nor would that solve the problem, that traditional mainframe monitoring solutions providing their data to these products can't provide insight into such long running BMPs. Tracking every single request starting on the distributed site would be costly and still an imcomplete approach to this, because these long running, MQ messages consuming BMPs are getting parts of their workload from other mainframe applications and the origin of those kinds of workload lies partially outside of what a tracking-based end-to-end monitoring solution could capture (like BMP processing DB2 or IMS databases, like APPC requests from mainframe systems of business partners, etc.). There are reasons like this on why application-based monitoring approaches are relevant.

Thank you for this RFE.

The use case provided seems to be focused on using z/OS Connect EE to facilitate monitoring requests to help extract metrics and data from IBM Z subsystems.

For monitoring use cases on IBM Z we recommend using monitoring integration solutions such as:
IBM Common Data Provider (CDP)
IBM Z APM Connect

These, and other solutions like them, allow monitoring metrics and data to be captured and sent from various subsystems and to a wide verity of modern monitoring frameworks and dashboards.

Whilst "plain text" is a valid option for OpenAPI requests and responses, we have not yet encountered a business API use case that would be more consumable from having un-structured data in the payload, hence the focus on JSON to this point in time.

If you could provide a business use cases for "plain text" payloads and how that will provide an improved API design and user experience to end consumers of the API, that will help us to assess the priority of this requirement.

Many thanks.