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 (https://ideas.ibm.com).


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 (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - 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
Categories Languages - RPG
Created by Guest
Created on Mar 6, 2023

Enhance the POS keyword to support a location of *NEXT similar to OVERLAY.

The OVERLAY keyword is required when its "field" parameter is the data structure name. However OVERLAY does not allow *NEXT for the position of that field, a hard-coded value must be specified otherwise it defaults to 1.

The POS keyword support overlaying using the data structure name but does not support a position of *NEXT. 

 dcl-ds rtn_Struct_t Qualified template;
              choice_text char(30);
              choice_list_count int(5) OVERLAY(rtn_struct_t);
              objtypes likeDS(choices_t) dim(500) OVERLAY(rtn_struct_t:*NEXT); // Fails/invalid due to DS name being used
           end-ds;

 dcl-ds rtn_Struct_t Qualified template;
              choice_text char(30);
              choice_list_count int(5) POS(1);
              objtypes likeDS(choices_t) dim(500) POS(*NEXT);  // Fails/invalid
           end-ds;

Idea priority High
  • Guest
    Reply
    |
    Mar 8, 2023

    Thanks for the suggestion. While that isolated solution does work in this context, it does not work as soon as you get 2 instances of this condition.

    dcl-ds myStruct Qualified;
    choice_count int(10);
    objType varchar(50);
    choice_text char(30); POS(1);
    some_other_subfield varchar(80) POS(31); // Why not *NEXT?
    another_subfield varchar(28) POS(<now I have to do math ;(> ); Why not *NEXT?

    end-ds;

  • Guest
    Reply
    |
    Mar 8, 2023
    Thank you for the clarification.

    You could move the simple choice_text subfield after the other two subfields, and define choice_text with POS(1).

    dcl-ds rtn_Struct2_t Qualified template;
    choice_list_count int(5) inz(88);
    objtypes varchar(50) inz('OBJTYPES');
    choice_text char(30) POS(1);
    end-ds;

    You could also define the data structure more clearly as a union of two types of information. However, this type of data structure is not currently allowed by embedded SQL.

    dcl-ds rtn_Struct3_t Qualified;
    dcl-ds single_choice_text pos(1);
    choice_text char(30);
    end-ds;
    dcl-ds multiple_choice_texts pos(1);
    choice_list_count int(5) inz(88);
    objtypes varchar(50) inz('OBJTYPES');
    end-ds;
    end-ds;

    IBM does not intend to provide a solution to this Idea at this time, so it is being closed. This Idea does not align with the strategy for future investment in this component.

    There is already an Idea requesting more support for nested data structures in embedded SQL: "Allow more than 1 level of qualified datastructures in SQLRPGLE" https://ibm-power-systems.ideas.ibm.com/ideas/IBMI-I-2874.
  • Guest
    Reply
    |
    Mar 7, 2023

    ctl-opt actgrp(*NEW);

    dcl-s X INT(10);

    dcl-ds rtn_Struct_t Qualified template;

    choice_text char(30);

    choice_list_count int(5) POS(1) inz(88);

    objtypes varchar(50) inz('OBJTYPES');

    end-ds;

    dcl-ds struct likeDS(rtn_Struct_T) Inz(*LIKEDS);

    *INLR = *ON;

    X = X + 1;

    return;

    In the above example, the OBJTYPES subfield appears in position 30. I need it to appear after the CHOICE_LIST_COUNT subfield in memory. The only way to do that is to "count the bytes" of the subfield before it (CHOICE_LIST_COUNT in this example) and hard code POS(3).

    I want a way to indicate that OBJTYPES is in the next position relative to the prior POS keyword subfields. So a POS(*NEXT) would be great in this context since OVERLAY doesn't work in this situation.

    This would not impact any existing code since the lack of a POS keyword would continue to work as is, while a POS(*NEXT) would simply look at the prior POS and calculate the new location. Clearly some rules would need to be inplace, but consecutive subfields with POS(n) followed by POS(*NEXT) should work better.

    I suppose a work around today is to create another DS template and instead of my 2 subfields, I add another subfield and LIKEDD(newTempl). The challeng is that half the time embedded SQL doesn't always work with RPG's cool nesting levels so this would also help in that context. Thanks.

  • Guest
    Reply
    |
    Mar 6, 2023
    Can you provide more detail about the effect that the proposed POS(*NEXT) would have for the position of the subfield. In the example given, what position is required for the objtypes subfield?

    Note that OVERLAY(dsname:*NEXT) means the same thing as not coding the OVERLAY keyword at all. For a data structure, *NEXT does not mean "next after the previous subfield", it means "next after all previous subfields", which is the same as what happens when you don't code the OVERLAY keyword for the subfield.

    OVERLAY(dsname:*NEXT) is allowed in a fixed-form data structure definition. If you try coding your data structure in fixed-form D specifications, you can see the effect that OVERLAY(dsname:*NEXT) has on the subfield.