• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • 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?

    –Nathan

    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.

    –Ted

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags:

    Sponsored by
    VISUAL LANSA 16 WEBINAR

    Trying to balance stability and agility in your IBM i environment?

    Join this webinar and explore Visual LANSA 16 – our enhanced professional low-code platform designed to help organizations running on IBM i evolve seamlessly for what’s next.

    🎙️VISUAL LANSA 16 WEBINAR

    Break Monolithic IBM i Applications and Unlock New Value

    Explore modernization without rewriting. Decouple monolithic applications and extend their value through integration with modern services, web frameworks, and cloud technologies.

    🗓️ July 10, 2025

    ⏰ 9 AM – 10 AM CDT (4 PM to 5 PM CEST)

    See the webinar schedule in your time zone

    Register to join the webinar now

    What to Expect

    • Get to know Visual LANSA 16, its core features, latest enhancements, and use cases
    • Understand how you can transition to a MACH-aligned architecture to enable faster innovation
    • Discover native REST APIs, WebView2 support, cloud-ready Azure licensing, and more to help transform and scale your IBM i applications

    Read more about V16 here.

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Goering Bolsters iExcelGen with Better Automation PeopleSoft Says It’s Working Hard to Make a Better World

    Leave a Reply Cancel reply

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • Liam Allan Shares What’s Coming Next With Code For IBM i
  • From Stable To Scalable: Visual LANSA 16 Powers IBM i Growth – Launching July 8
  • VS Code Will Be The Heart Of The Modern IBM i Platform
  • The AS/400: A 37-Year-Old Dog That Loves To Learn New Tricks
  • IBM i PTF Guide, Volume 27, Number 25
  • Meet The Next Gen Of IBMers Helping To Build IBM i
  • Looks Like IBM Is Building A Linux-Like PASE For IBM i After All
  • Will Independent IBM i Clouds Survive PowerVS?
  • Now, IBM Is Jacking Up Hardware Maintenance Prices
  • IBM i PTF Guide, Volume 27, Number 24

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2025 IT Jungle