ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Pre-ILE RPG Puzzle

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Pre-ILE RPG Puzzle

    Hi, all. I've had the good fortune of being able to do almost all of my RPG programming in the ILE environment, but I've maintained older RPG, too. In continuing my assignment of converting 15-30-year-old code from a purchased ERP package (which I will not name, for the protection of people whose initials may be "J.D.E."), I've come across a subroutine that starts with the following two lines of code:

    Code:
    C*
    CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq.
    C*                     
    C*    Define Parameters
    C*                     
    CSR                 MOVE      #MCU          #MCU             12
    CSR                 MOVE      #FILE         #FILE            10
    If I'm correct in understanding that subroutines (unlike subprocedures) share global memory, it seems to me that this is not "instantiating" local copies of variables #MCU and #FILE, but just moving the fields to themselves. But this makes no sense!

    So, what am I missing? What might be going on?

  • #2
    Actually it does make sense in a world where you have no parameter capability.

    Say the subroutine's purpose was to add a month to a date. You want the routine to be able to function of any date field so you have two choices. A) Produce a copy of the standard routine and change the names to those of the field(s) involved or B) Use a work field in the subroutine and move the field(s) you want to operate on into the work field(s) prior to the routine's logic.

    In your example you are already in a subroutine - are you about to call another?

    P.S. If this is an ongoing project try to squeeze a few $s out of the company and buy the Linoma Toolbox (check - you may already have it) it will save you a lot of time and effort. If you have more $s try Arcad's tool - more capable but also more expensive.

    Comment


    • #3
      My guess would be that those lines are for the purpose of defining the length of the work variables since there was no such thing as D specs in RPG III.

      Comment


      • Jerry G
        Jerry G commented
        Editing a comment
        Thanks, Brian; you may be on to something.
        I've learned to expect what I regard as some VERY BADLY STYLED code in this product. Variables may be defined in ANY subroutine, and referenced by any other subroutine, relying on the "globality" of pre-ILE memory. For example, subroutine B may reference a variable defined in subroutine A. And subroutine B may be incorporated via a /COPY directive into dozens of programs. And it just relies on all those dozens of programs also having a /COPY directive for subroutine A.
        So, this may just happen to be the subroutine in which they decided to define #MCU. (And before D-specs, this was just how it was done.[?])
        Just shoot me.

    • #4
      I'm not sure I follow you, JonBoy. But, yes, these are the first two lines of a subroutine. If this were a subPROCEDURE, with it's own memory allocation, I'd understand.
      We went with the Arcad-Transformer RPG tool, the licensing for which worked better for us (especially since we don't already have the [nice] base Linoma product). It generates D-specs at the program global level:
      Code:
      DCL-S #MCU            CHAR(12);
      DCL-S #FILE           CHAR(10);
      ... and converts the subroutine code to just:
      Code:
      #MCU = #MCU;   
      #FILE = #FILE;
      *sigh*
      ...

      Comment


      • #5
        Darn it - I missed that they were the exact same variable name. Brian is right - it is just very old code that is defining the variables.

        I would have a word with Arcad though. Their tool should be intelligent enough to drop those assignments.

        Comment


        • Jerry G
          Jerry G commented
          Editing a comment
          Thanks, JonBoy. This seems an odd way to define a variable ... but given RPG at the time, where else, I guess?! Live and learn. :-)

          I like the core of Arcad's conversion tool, but some of the "accoutrements" around the core (tools, UI, support portal) could definitely use some work.
          All the best!

      • #6
        Back in the "olden days" all data was basically defined in input/output files. So just I and O specs. There were no D specs so work fields were defined on the fly in the calcs.

        Comment

        Working...
        X