Skip to Main Content
IBM Power 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:

Post your ideas

Start by posting ideas and requests to this portal to enhance a Power product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas and add comments to ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The Power teams will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notification on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.


Specific link you will want to bookmark for future use

IBM Unified Ideas Portal - https://ideas.ibm.com/ - Use this site to create or search for existing Ideas across all IBM products that are outside of Power, and track all of your personal interactions with all Ideas.

Status Not under consideration
Workspace IBM i
Categories Networking
Created by Guest
Created on Sep 11, 2021

SSL enable give/takedescriptor API's

The give/takedescriptor API's allow one to exchange the socket between a listener (main) program and a submitted client job.

This however only works for non-SSL connections which makes it impossible to use the concept for accepting multiple simultaneous clients.

Please provide a method for transferring the SSL state of the socket to a client job.


Use Case:

The give/takedescriptor API's allow one to exchange the socket between a listener (main) program and a submitted client job.

This however only works for non-SSL connections which makes it impossible to use the concept for accepting multiple simultaneous clients.

Please provide a method for transferring the SSL state of the socket to a client job.


Idea priority Urgent
  • Guest
    Dec 6, 2021

    We are happy to see you were able to split the secure handshake processing into the 2nd process, by passing the connection first, and then securing it in the 2nd process. Since there is an alternate working design and IBM does not intend to provide a give/takedescriptor solution, the request is being closed.

  • Guest
    Oct 14, 2021

    The CEAC has reviewed this requirement and recommends that IBM view this as a MEDIUM priority requirement that should be addressed.

    Background: The COMMON Europe Advisory Council (CEAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CEAC has a crucial role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community and has therefore reviewed your RFE.

    To find out how CEAC help to shape the future of IBM i, see CEAC @ ibm.biz/BdYSYj and the article "The Five Hottest IBM i RFEs Of The Quarter" at ibm.biz/BdYSZT

    Therese Eaton – CEAC Program Manager, IBM

  • Guest
    Oct 12, 2021

    I can confirm that the "split the accept/upgrade process" works. The SSL logic is now transferred from the "listener" job to the submitted "client" job.

    A side note is however that the "listener" job is not aware that the "client" job might fail due to an incorrect SSL negotiation (so far I don't know if there are other implications of this split logic).

  • Guest
    Oct 7, 2021

    I'm currently evaluating the "split the accept/upgrade process" but still have a few issues.

    I'll report back in this RFE once I have more information if this is a viable solution.

  • Guest
    Oct 6, 2021

    Thank you for providing the additional information. IBM understands the requirement and will evaluate it as part of the plan process. A response will be provided after evaluation is complete.

  • Guest
    Sep 21, 2021

    The CAAC has reviewed this requirement and recommends that IBM view this as a medium priority requirement that should be addressed. Although there are viable work-arounds, this request is one of the more worthwhile to implement.

    Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.

    For more information about CAAC, see www.common.org/caac

    Nancy Uthke-Schmucki - CAAC Program Manager

  • Guest
    Sep 21, 2021

    Hi,

    The application originates from a "single" connection where the accepted socket was upgraded to an SSL socket and being used to communicate with the client in SSL mode. By upgrading the program to a "multiple client" version the socket logic was kept together, after which the socket was passed to the client. I could try to split the accept/upgrade process between the listener program and the actual server program as you seem to suggest.

    The new process runs under the same userprofile by default however this isn't a strict requirement (however authority shouldn't be a problem). If the same userprofile is however a requirement, it should be no problem to respect this requirement.

    Yes, the GSKit API's are used, ie. gsk_secure_soc_open, gsk_attribute_set_numeric_value, gsk_secure_soc_init.

  • Guest
    Sep 20, 2021

    Hello Paul,
    Thank you for taking the time to submit this request. We would like to get some more information to further understand and assess your Request for Enhancement.

    Why does the application server pass the secure connection between processes? Can the server process accept the new TCP connection and pass the connection to have the client process establish the secure connection rather than pass the connection after the secure session is established? Does the new process run under the same user profile as the server process listening for connections or what authority does the profile have for the giving and taking processes? Does your application use the GSKit APIs to establish the secure connection?