Skip to Main Content
IBM Sterling

This portal is to open public enhancement requests for IBM Sterling products and services. 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 (

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 ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Created by Guest
Created on May 1, 2023

Add capability to hard fail SSL error processes

When an SSL handshake error occurs, the process is placed in HO ER status.  This does not trigger the same error alerts as file transfer failures when the process is pushed into HO ER status.   

If the same alert triggering would occur from session setup failure as transfer failure, we wouldnt miss processes not being transfered in a timely fashion.

If there was a parameter for how to handle SSL Session errors, Hold or Fail.  Default Hold.  Users who do not want to utilize this Enhancement Request would not have to change anything.  The Processes would still go to Hold Error.   For those who code FAIL, if there is a SSL handshake error, the process would end.  IT would not stay in the Process queue.

  • Admin
    Jun 9, 2023

    Updating his case to "Future Consideration" based on the internal review. We will be considering based on the overall priorities for one of the future releases. Thanks for your suggestions and appreciate your patience.


    Product Management

  • Admin
    May 24, 2023

    Thanks Chad for providing the detailed response. This is now clear to me. I will discuss this further with development and queue this up for the future implementation. You should see an udpate to the status once we confirm it for a specific release.


    Product Management

  • Guest
    May 23, 2023

    Greetings Vijay,

    I thought I responded a few days ago, but dont see my response. so I will try to rewrite again.

    The Security.Notify will only work if the userid who submitted the batch job is a valid user and not a Scheduler application. Since the scheduler is submitting the CD process, it will not acknowledge the response.

    Yes, Im asking for a new parameter on how to handle SSL errors. Either Flush the process or leave it in the TCQ as HO HE. I think this parm can be a global parameter with the ability to override with the netmap entry definitions. But for us, we would use this for Global. But I can see customers would want to override this on the netmap entries.

    Here is my take...

    We validate our connectivity and Secure+ with our customers before we go live. Once we go live, we should not expect to having Secure+ issues anymore. So, if we start failing to complete the handshake with the adjacent.node, we want the process to be flushed. This will produce a non RC=00 or 04 that will trigger Broadcom's Solve:File Transfer monitoring and system alerts are produced. with the process going to HO HE, SFT does not trigger that the transfer failed.

    Typical messages start with CSPA, There are alot of them, but in today's search, we see the following:.

    CSPA001E Node definition for remote Secure+ node missing

    CSPA004E Security Violation - PNODE authentication error

    CSPA202E TLS/SSL handshake failure, reason=Socket closed by remote partner

    CSPA202E TLS/SSL handshake failure, reason=remote partner indicates sent certificate is not valid

    CSPA202E 456 ICSF callable service returned an error

    Again, there are more than what I just posted.



  • Admin
    May 16, 2023

    Thank you for submitting your idea. After discusing this with our deveopment team we need some more information about the trigger of failure? What sort of failure trigger is intended here? Is additional messages expected OR just the process flush. If you can provide a screenshot that will greatly help.

    BTW, You can explore the initparm param - SECURITY.NOTIFY, a parameter available which provide notification on failure specific to security errors.

    We believe you might be asking for an option where processes that fails due to handshake error can be flushed rather than going to HO-HE status. Is that right? If we have to implement this we think it might be most useful as a NETMAP (node level) option rather than a global INIT parameter. What do you think?

    Once again thanks for your time to put this request and appreicate if you can get back with more information as mentioned above.


    Product Management