Best practices working with an .i file & running specific procedures

[HT3]

Hi All,

I have inherited some code from an old colleague, at the moment it runs 12 different procedures but they are separated by country (I.E. 3 for country A, 3 for country B and 3 for country C).

Two current issues........
The code is 2800 lines (Not large I know).

1. As the procedures are very similar, when making changes I get confused with which country I'm making the amendments for. I find myself making a change in the wrong place. This is slowing me down and I've got to run testing for all countries in case changes have been made to the incorrect procedure.

2. I've got to a minimum of 4 other countries to add... taking my total number of procedures to 28 and increasing the number of lines in the code to 5000.

Due to the reasons mentioned above I think the best way for me to proceed is to separate the procedures into include files by country. I will know I'm making the change in the correct place and reducing my testing.

I'm aware this will be tedious when compiling the code....

I know how to call a include file and run it, what I'm struggling with is calling a include file but only running 1 of the three procedures in it. How do I specify the code to run procedure 3 in the include file. I do not want 28 include files....

I'm not set on stone on the above approach, so any advice or thoughts are welcome.

Thanks

 

[Rob Fitzpatrick]

Warning: coding advice below from a DBA

You don't call an include; it isn't a subroutine. It is a way of encapsulating a piece of code so it can be written once and reused in more than one procedure. These days the common use case is for defining data members like temp-tables or datasets that will be used in several places.

When you reference an include file in some other source file, the code in the include file becomes a part of the code of the parent compile unit at compile time.

E.g.: foo.p:

/* foo.p */
display "hello" skip.
{include/bar.i}
display "world" skip.

include\bar.i:

/* start of bar.i */
display "in bar.i" skip.
/* end of bar.i */

compile .\foo.p debug-list foo.dbg

Debug listing for foo.p:

        1   /* foo.p */
        2   display "hello" skip.
        3
        4   /* start of bar.i */
        5   display "in bar.i" skip.
        6   /* end of bar.i */
        7
        8   display "world" skip.

run .\foo.p

┌────────┐
│hello   │
│in bar.i│
│world   │
└────────┘

If your parent procedure has an include, and the include file defines internal procedures, the parent code can RUN those IPs just as if they were defined in the parent.

(This can get into discussions and debates on how to encapsulate code, e.g. with classes. You can reads the OE docs for a better explanation of that than I can provide.)

It sounds like you have inherited some redundant code that could be consolidated into a single procedure by parameterizing the country code. If different countries need different handling there are various ways to do that. It could be something simple like a CASE statement that leads to different code blocks, e.g. RUN statements for different internal procedures. But I don't know your requirements so it isn't really appropriate to talk about implementation details. That said, I would avoid using includes for the different pieces of logic.

The point is that you should make your business logic as generic as possible and avoid having a large and potentially increasing number of source files that contain very similar business logic and will be a maintenance headache.