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 Feb 5, 2016

Enhanced iProject

Now that we have completely free format starting in column 1 with unlimited columns, the next step is for the tools to support source in the IFS. I would like an enhanced iProject that resides in the IFS, and does not necessarily tie back to source physical files. I want to be able to segregate portions of my application by folder, and name programs with long file names.

The only exception to this would be device files. These could still be stored in a folder that is tied back to a specific source physical file, but that would have to be a property of the folder in the project. In the project metadata, you could tie a folder to either a library and source physical file, or to an IFS directory. The IFS directory could exist in both cases. But, if the project folder was a "surrogate" for a source physical file, the folder in the IFS would just contain metadata.

The ultimate goal of this would be to get to a point where we could use a tool like GIT to manage our source. The hybrid source physical file folder would not really work directly, but either a work around could be developed, or something to replace the DDS for device files. In fact, device files are the only thing left to address outside the RDi tooling since the database can be developed using SQL DDL, which can be run directly from the IFS using RUNSQLSTM.

Use Case:

Create and enhanced iProject in the IFS.

|-> customer
| |-> Protorypes.rpgle
| |-> ListCustomers.rpgle
| |-> ChangeCustomer.rpgle
| |-> AddCustomer.rpgle
| |-> DeleteCustomer.rpgle
| |-> customer_service_program
| | |-> Prototypes.rpgle
| | |-> GetCustomerName.sqlrpgle
| | |-> GetCustomerAddress.sqlrpgle
| | |-> IsValidCustomer.sqlrpgle

You get the point, would still have to provide a way to bind service programs, maybe an XML tool to describe the modules to be bound together, and which procedures to be exposed in the binding source. Program and module object names can be defined in the H specs of the respective source files. Each folder should have a bit of metadata to indicate where to generate objects, this would make binding service programs easier. Or a specific make tool like ant, or extensions to ant could be developed to make the build easier.

Idea priority Medium
  • Guest
    Mar 15, 2022

    Thank you for taking the time to submit your request. After careful consideration, we know that we cannot deliver your requested enhancement in the near term, so it is being declined. However, your request does align with the future strategy of our product and we believe it may have future value, so we will add it to an internal list for us to keep in mind for the future.

  • Guest
    Sep 19, 2020

    We have reviewed this requirement and we feel it would be a beneficial enhancement to the product. We hope to be able to add it to our development plans in the future.

  • Guest
    Apr 21, 2016

    We see 2 different requirements included in this RFE.

    The requirement to synchronize the source with the IFS already exists in Please refer to it for current status and add your votes to it.

    But the requirement to provide build support for IFS is unique. We are keeping this RFE open specifically for the requirement of building source in the IFS. Status has been updated to Uncommitted Candidate.

  • Guest
    Feb 18, 2016

    A preliminary evaluation of this request indicates that it is consistent with our business strategy. Further evaluation of this RFE is underway.

  • Guest
    Feb 5, 2016

    Just to be clear, the goal of this RFE is for RDi to play nicely with source in the IFS so that Git becomes a viable alternative for source control. This does not include the make tools that would be necessary to build everything properly.

    For example while some tools like most of the CRTBND*, and CRTSQL*I (for ILE) compilers support source in the IFS, CRTBNDCL does not. This could be handled with a make tool. In addition device files and commands can not currently be created from source in the IFS.