Define Compile-Time Array Data in D-Specs
September 8, 2004 Hey, Ted
For performance reasons there are certain tables that I would prefer to implement as compile-time arrays rather than as physical files. But I don’t want to hard-code the compile-time array definitions in each RPG program that uses them, since that would require manual modification of each program if an array’s definition or data changes. Loading each array from a file at program startup is also an option, but I’d prefer to avoid the unnecessary I/O. I came up with a method to store compile-time array definitions in a copyable source member, but it has one little problem.
Here’s my idea. I created a source member containing both definition and data of a compile-time array.
/if not defined(CTDATA) D NbrOfRegions c const(5) D RegionNbr S 2 dim(NbrOfRegions) D ctdata PerRcd(1) D RegionName S 8 dim(NbrOfRegions) D alt(RegionNbr) /eof /endif **ctdata RegionNbr N NORTH S SOUTH E EAST W WEST MWMIDWEST
Any program that needs the regions table can access my source member at run time, defining or undefining the CTDATA condition appropriately.
D Region s 2 D R s 10i 0 D DtlRegion s 8 D D/undefine CTDATA D/include mylib/tables,Regions /free R = %lookup(Region:RegionNbr); if (R > *zero); eval DtlRegion = RegionName (R); else; eval DtlRegion = 'REG ' + Region; endif; *inlr = *on; /end-free D/define CTDATA D/include mylib/tables,Regions
If the region data changes (a region is added, deleted, or renamed), I need only revise the source member that contains the region data and recompile the programs that use the array.
This method works fine as long as there is only one compile-time array in the program. When I try to include a second source member that contains a compile-time array, my technique breaks down. The included D-specs are perfect, but the compile-time array data is not. The compiler does not recognize that the first compile-time array data set has ended, and tries to treat the second /include (or /copy) as another data record for the first compile-time array.
Do you know of another method that would accomplish my goal?
I had never considered this idea before, so your question was intriguing to me. I came up with a method that will do what you want, but I should tell you that I have never used this method in production.
It occurred to me that if you could load the data through the D-specs, similar to the way COBOL programmers define compile-time array data in the data division, you would be rid of the compiler’s insistence on treating compiler directives as compile-time array data.
Here’s your region data defined in D-specs.
D NbrOfRegions c const(5) D RegionData ds D 10 inz('N NORTH ') D 10 inz('S SOUTH ') D 10 inz('E EAST ') D 10 inz('W WEST ') D 10 inz('MWMIDWEST ') D RegionBase s * inz(%addr(RegionData)) D RegionArray ds based(RegionBase) D RegionElem 10 dim(NbrOfRegions) D RegionNbr 2 overlay(RegionElem:1) D RegionName 8 overlay(RegionElem:3)
The RegionData data structure takes the place of the compile-time array dataset that is normally coded at the end of the source member. RegionArray contains the definition of the compile-time array data in a slightly different format than the one to which you’re accustomed. Each record of the array data is an element of the RegionElem array. The OVERLAY keyword lets you break RegionElem into the two arrays you access: RegionNbr and RegionName.
To make this technique work, it is necessary to assign the RegionData and RegionArray data structures to the same address in memory. I did this by creating pointer variable RegionBase. This pointer contains the address of RegionData. Since RegionArray is based at the address contained in RegionBase, RegionArray overlays RegionData in memory.
You will need only one /include (or /copy). Place it anywhere in the D-specs.
If you use this technique, you will be able to define multiple compile-time arrays in external source members. Since I have not used this method in production, I would like to hear from anyone who tries it.