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

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;

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.

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.

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.