IBM Z Software


This portal is to open public enhancement requests against IBM Z Software products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas

  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Add a new idea Subscribe
Status Not under consideration
Workspace z/OS Connect
Created by Guest
Created on Jan 8, 2019

RELATED IDEAS

z/OS Connect should provide appropriate HTTP error codes on errors within z/OS Connect or backend systems

Since a short time it is now possible to define HTTP return codes in z/OS Connect depending on codes the application sends back its response message, but in error Scenarios z/OS Connect still doesn't provide an appropriate HTTP error code. Instead of this zCEE provides either HTTP error code 500 together with an error messages a developer not necessarily understands respectively no content or it doesn't provide any response. But a better handling of errors by the client and for a better understanding of the Problem by developers without mainframe skills, z/OS Connect should always provide appropriate HTTP error codes on any errors within z/OS Connect or its backend systems like IMS, or CICS.

For instance:
Authentication problem in z/OS Connect / IMS Connect -> 401 Unauthorized
Attempt to access something within z/OS Connect or the backend system without permission -> 403 Forbidden
Transaction/program stopped -> 503 Service unavailable
Transaction/program unknown to the backend system -> 404 Not Found
No response message before timeout -> 408 Request Timeout
Input message too long (for instance larger than IMS SEGSIZE) -> 413 Payload Too Large
Input message not accepted because of any flood control mechanism (for instance IMS OTMA flood control) -> 429 Too Many Requests
zCEE failure or subsystem abend -> 500 Internal Server Error
Certificate error - 495 SSL Certificate Error
Certificate not provided with the request - 496 SSL Certificate Required
Wrong protocol used - 497 HTTP Request Sent to HTTPS Port
and so on...

In addition to this it should be possible to define user-defined HTTP error codes for transaction/program abends in backend systems like IMS or CICS depending on the abend code.

For instance:

IMS abend code U3303 - User-defined HTTP error code 471 Database unavailable
IMS abend codes U3310 and U0123 - User-defined HTTP error code 472 Lock conflict
IMS abend codes U0462, U0101, ... - User-defined HTTP error code 473 Application error
IMS abend codes U0474 and U0240 - User-defined HTTP error code 474 Cancelled by Operator
All other abend codes - User-defined HTTP error code 476 Unknown error

Idea priority Medium
  • Guest
    Reply
    |     Sep 23, 2021

    i am a bit disappointed: this is a very important question.
    Bye

  • Guest
    Reply
    |     Sep 23, 2021

    i am a bit disappointed: this is a very important question.
    Bye

  • Guest
    Reply
    |     Nov 25, 2019

    Thank you for this RFE. IBM z/OS Connect EE is a continuous delivery offering, and aims to satisfy the needs of a rapidly evolving market segment. It is information that like this that will help to improve the product.

    Unfortunately, as it stands, this RFE is too broad for us to make any actionable progress on. From discussions with the community it covers many different use cases, from dev to production, across many different personas. In some cases the suggestions offered here may be appropriate solutions, in others they certainly are not. Also changing the error responses could introduce breaking changes in behaviour which would be difficult for both us and our customers to manage as part of a continuous delivery update.

    As such this RFE is being rejected.

    However, the points raised here and through the extended discussions we've had with the community around this RFE have been heard loud and clear by the z/OS Connect EE team. So this RFE will provide valuable input into how we approach debug, problem determination and monitoring as we continue to evolve the product.

  • Guest
    Reply
    |     Oct 4, 2019

    Providing an "Internal Server Error" for any kind of problem is neither helpful from an problem determination stand point nor from an automated reaction stand point. On the problem determination side both the developers in dev/test as well as the application owner in prod should to able to get idea of what the problem might be without needing to call / open a ticket with the people who are responsible for operating z/OS Connect EE all the time. On the automated reaction side it is interesting to react correctly in the application. In some cases the end user should get an clear error text (for instance in the not autorized case), in others the front end application could take automated actions to solve the problem (for instance it could use z/OSMF or Zowe APIs to start a stopped transaction again) and then there are also situations in which the application could deactivate some a function and show an info page to the end user to prevent useless requests in a persisting backend system problem situation (also in this case z/OSMF or Zowe APIs could be used to reguarly check whether the backend function is available again). There are lot's of possibilities on how more specific response codes could be used.

    Regarding the fact, that z/OS Connect EE in its today's implementation won't know about the problem cause in some of the samples I brought: The service providers are usually getting back error messages from the back end system, which can be interpreted by the service provider to provide an appropriate response code. Backend systems also could be enhanced to provide clear error messages in situations in which they don't provide them today.

    Regarding security concerns: There could be some configuration / policy in z/OS Connect EE which tells who gets a more specific responde code and who don't.

    Feel free to setup a call with me to discuss everything in detail. In addition to this one of the z/OS Connect EE design feedback calls could be used to discuss this.

  • Guest
    Reply
    |     Sep 17, 2019

    Thank you for this RFE.

    While the list above seems mostly sensible in some cases it suggests things that would be:
    a) Impossible for z/OS Connect EE to know
    b) Not appropriate to share with an end user since it gives away too much information about the backend implementation, which in some cases could be a security concern.
    c) Just as valid as the error code that z/OS Connect EE uses today in that specific situation

    Given the interest/votes this RFE has received recently we would like to clarify the key use cases to understand the real need.

    The text in this RFE suggests that the focus is on helping a z/OS Connect EE user debug API mappings/errors during development.

    We would appreciate some comments from the community/voters to help us understand if:
    a) the "debugging" use case is for the z/OS Connect EE user OR the end API consumer?
    b) What are the most important error conditions for to identify?
    c) Why are they the most important?

    Thank you again for your continued engagement

  • Guest
    Reply
    |     Jul 9, 2019

    Another kind of error should be addressed is, ie, the following:
    {"errorMessage":"BAQR0429W: API apiname encountered an error while processing a request under URL http://server.domain.com:22222/apiname/parm1234","errorDetails":"com.ibm.zosconnect.wv.transaction.messages.walkers.MessageWalkerException: GMOMW0005E: A data type conversion error occurred while the leaf field FIELD_NAME of service interface service_name was converted: IWAA1111E: String parm1234 exceeds maximum length of 7.."}

    A possible mistake is to insert one or more character in the input field maximum accepted characters.
    We would have a better and shorter error message, using an http error code.

  • Guest
    Reply
    |     Jan 9, 2019

    For asynchtimeout requests, the HTTP Code should be 504...shouldn't it? It's currently gets set to 503.

0 MERGED

Raise more error details to calling client

Merged
When an error occurs in a service in CICS, an ABEND ASRA for instance, it would be very helpful if the description of the error was raised up in the detail field up to the API calling client. For instance, instead of of receiving just ""errorMessa...
over 5 years ago in z/OS Connect 1 Not under consideration

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.