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 May 6, 2016

RDi CL formatting for declaring variables with defined storage

Add a preference to indent DCL statements for variables with STG(*DEFINED).

Use Case:

Declare an incoming parameter for a qualified object and then declare the object name and library. With the indentation it would look similar to the following:

dcl var(&ParmObj) type(*char) len(20)
dcl var(&ObjName) type(*char) stg(*defined) len(10) +
defvar(&ParmObj 1)
dcl var(&ObjLib) type(*char) stg(*defined) len(10) +
defvar(&ParmObj 11)

With the indenting, it is very quick and easy to see variables defined from the "parent" variable.

Idea priority Low
  • 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
    Jun 21, 2016

    Although the theme of this request is consistent with our business strategy, it is not committed to the release that is currently under development.

  • Guest
    May 10, 2016


    No it is not necessary to define them immediately after the DEFVAR. I would be fine with only indenting if the *DEFINED variable was only indented after the DEFVAR variable. That would mean more parsing work to make sure the indent is properly handled. I think a better way would be to make this option a preference. If someone codes that way, have the preference turned off.

    I personally would consider coding the *DEFINED variable remote from the DEFVAR variable very confusing or really just a plane bad practice. When doing my code review, I would take back anything like that to the developer who coded it and have them to change it.

    Even if I do a *DEFINED variable after an INCLUDE, I do it immediately after the INCLUDE so that someone following my code has a chance at understanding it.

  • Guest
    May 9, 2016

    Is it necessary to define these variables immediately following the variable they overlay? If not, indenting them could be misleading.