Skip to Main Content
IBM Power Ideas Portal

This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. 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 Not under consideration
Workspace IBM i
Created by Guest
Created on Jun 16, 2021

Block QZDASOINIT started as BCI job in QSERVER enhancement

Prevent database prestart jobs to start as BCI jobs is also ending the jobs rerouted to other subsystems when we use the solutions provided by the Doc.: #638059 historical #391825917

Use Case:

Client has split his service jobs over different subsystems for load and application purposes.
By default all connections are served by QUSRWRK. When we end this subsystem, the QZDASRVSD deamon is starting a new BCI job in QSERVER so defeating the purpose of ending the QUSRWRK subsystem.
Ending the host server*DATABASE, as solution B proposed in the doc is not a solution as this ends all service jobs,in all subsystems.
Implementing the solution A, provided by the Doc. results in also no longer serving the jobs in the other subsystems.
It seems that the deamon job is no longer looking further at the re-routing configuration to serve the other database jobs.

Idea priority High
  • Guest
    Nov 22, 2021

    Thank you for submitting your request. I agree this would be most useful. However, after thinking about this some more, I keep circling back to the limitation that we do not know the user profile name at the time the first request is put to the server (running in QUSRWRK, in this case). Therefore, we can't reject only the users that aren't to be rerouted because we don't know which ones are to be rerouted until we make that first connection.
    There might be other ways to configure things that might get you closer to what you are trying to accomplish, but I don't see a way to make it work for your specific use case, which seems like a very common setup.

  • Guest
    Aug 2, 2021

    Moving this to "under consideration" for further evaluation. But it is unlikely this can be accomplished with the limitations of the current design.

  • Guest
    Jul 14, 2021

    Here is a link to the support document referenced in the Description:

    The following document further explains how the Route by User function works -

    The request cannot go directly to the subsystem configured for the route by user because the user name is not known at the time the first connection is made. So a connection must be made in the subsystem where the prestart job is configured or where the daemon job is running before it can be routed to the subsystem configured for a specific user.

  • Guest
    Jul 12, 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 @ and the article "The Five Hottest IBM i RFEs Of The Quarter" at

    Therese Eaton – CEAC Program Manager, IBM