• 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
    Raz-Lee Security

    The MFA Mobile App provides a secure and user-friendly way to add strong authentication without complicating access. It enables users to approve login requests or generate one-time passwords directly from their mobile device, ensuring that access is granted only after a second, trusted factor is verified.

    Learn More

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Sifting Through the Java Quagmire CRTDUPOBJ and Logical Files

    Leave a Reply Cancel reply

Volume 4, Number 30 -- September 8, 2004
THIS ISSUE
SPONSORED BY:

COMMON
iTera
Guild Companies

Table of Contents

  • Sifting Through the Java Quagmire
  • Define Compile-Time Array Data in D-Specs
  • CRTDUPOBJ and Logical Files

Content archive

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

Recent Posts

  • No Joke: Big Memory And Flash Price Hikes Coming April 1
  • Strategic Topics To Think About For 2026, Part 2
  • Guru: IBM i Job Log Detective Brings Structure To Job Log Analysis In VS Code
  • IBM Launches Hybrid Cloud Backup Product With Cobalt Iron
  • IBM i PTF Guide, Volume 28, Number 10
  • Why You Need To Think About Offsite Data Protection
  • IBM Gets Bob 1.0 Off The Ground
  • You Store The Crown Jewels In A Safe, Not In A Bucket
  • More Power Systems Withdrawals, And Some From Red Hat, Too
  • Price Increases Are Here, Or Pending, And For Sure For Memory

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