Re: Data structure field names

On 25 Apr 2012 04:10, Dave wrote:

One of our standards often imposes working with hideous data
structure names as parameters, which gives field name like

GhkrAdlMjr.CstTy for the customer type.

I'd like to be able to declare a local DS something like :

D wDS DS
D wCstTy
D wfld2
D etc.

which would have the same structure as GhkrAdlMjr. Then write:

wDS = GhkrAdlMjr;

And be able to refer to the customer type as wCstTy instead of
GhkrAdlMjr.CstTy throughout the procedure.

How can I do this? If I declare my wDS like the horribly named
DS, my field names will be wDS.wCstTy, etc.

Although Barbara already alluded to problems in making a copy, depending on where and how the alternate /copy/ is defined and maintained, the additional\redefined DS may still be acceptable in some scenarios.

Ignoring whether copying the data to a /local/ [additional\separate] DS from an original is required or desirable, and ignoring the chance of problems for changes or additions to the original without ensuring the same changes\additions in the alternate... Declaring the /local/ DS BASED with all of the subfields with new names defined LIKE the corresponding declaration in the original is a possibility. The basing pointer could be to the original or to a LIKEDS version of the original.

DGhkrAdlMjr ds
D CstTy 3a
D sf2 10i 0
D sf3 10i 0 inz
D* First example of a way to remap the above DS GhkrAdlMjr
D* for a copy, use LIKEDS, addressed by a based version
DwDScopy ds LIKEDS(GhkrAdlMjr)
DwDS@ S * inz(%addr(wDScopy))
DwDS ds based(wDS@)
D* subfields renamed; like( either qualified copy or original)
D wCstTy like(wDScopy.CstTy)
D wSubfld2 like(sf2)
D wEtc like(sf3)
D* Second example of a way to remap the above DS GhkrAdlMjr
D* refer to the original via based version, without a copy
DwDS@ S * inz(%addr(GhkrAdlMjr))
DwDS ds based(wDS@)
D wCstTy like(CstTy)
D wSubfld2 like(sf2)
D wEtc like(sf3)

The above examples assume a DS is consistently both contiguous and aligned storage. Of course the alternate name\copy of subfields could be handled separately in the same manner, as standalone fields, if just one or a few subfields were desirable to have different names. Using based storage and one pointer for many subfields is better for memory requirements than one pointer for each of many subfields separately.

FWiW:

Defining the original DS using a Macro[instruction] processor which exposes parameters for naming each subfield, or using some other type of pre-processor that operates against the shared\included original declarations, can automate making custom copies of a DS while preserving attributes but not names. In either case, the use of a pre-processor prevents mismatches [except names, which are of course intentionally may be different] across each different reference to the original declarative; i.e. automatic at effective /compile-time/.

The former is not generally helpful if such tooling is not already available and in-use. That is because the original copy of the declarative should be produced by the same macro definition, with /default/ parameter specifications, that will be used by others where preferred names override the defaults.

The latter is generally most helpful when the includes\copy activity can be intercepted, perhaps with macro language, in some manner which allows specifying the replacement names. Generally this technique is used to replace only one portion of existing names, such as a prefix or suffix; at least prefix, RPG already has a solution. Renaming many or all elements individually with this method would probably require a more creative solution than the typical use; possibly something like requiring a physical copy already in-line to the source that will be pre-processed or in the included source, where that inline copy has the replacement names associated somehow to the original names and the pre-processor keeps them in-sync.

Regards, Chuck