ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Loading in array from display file.

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

  • Loading in array from display file.

    Hi!

    I have an external defined display howing records found from the beginning or after SETLL.
    I use to load 2 record formats as follows:
    - step 1: display with title, command keys, headers and input fields to choose one record at a time, overlay indicator OFF;
    - step 2: display with variable line positioning to output data and with input field which will be ND if no data available;
    - step 3: same display as step 1, but with overlay indicator ON.

    To check all the input fields with a DOxx operation for an 'X' used to chose a record for update/viewing, I have to put all these input
    fields in an array.

    In RPGII it was very simple:
    - array definition in the 'E'-specs;
    - start and end position of whole array (or single element with index) in the 'I'-specs.

    In my case this meant just 3 lines of coding (if input fields contiguous on display file).

    Now it seems to me that the same needs more coding in RPGLE:
    - through 'D'-specs, overlaying DS, etc
    - or 'JX'-specs renaming FLD01-FLDn to ARR(1)-ARR(n), which is deprecated or inelegant (why?)

    Is there a way in RPGLE similar or equal to RPGII?

    TIA
    Arnaldo

  • #2
    Re: Loading in array from display file.

    You can still use program-defined screens in RPG IV, just as you would've done in RPG II. That will still work the way it always has.

    However, most people don't do things that way because they found it difficult to maintain. If you get your from/to positions wrong on the fields, what happens? A corrupt display. If you change the definition of a field, you have to re-code all the from/to positions. If you rearrange the fields on the display, you have to recalculate everything. It was discovered long ago to be difficult to maintain, and people prefer the externally defined method.

    Studies have shown that programmers spend 70% of their time working on understanding existing code, and less than 30% of their time actually writing code. So anything that makes the code easier to understand is a good thing. It's more important for the code to be easy to understand than it is to use fewer lines of code.

    Using "JX" to rename fields also still works in RPG IV (though, it did not work in RPG II). The problem with this is it requires your fields to always be input-capable, since it's done on input-specs. Still works fine, though, it's not very intuitive, and the code isn't very short, either.

    Using a data structure to overlay the screen names with an array is very easy to understand. It takes, what? Maybe 5 minutes of your time? That's not significantly longer than coding the I-specs for your "JX" technique. But it's very easy to understand, works for both input and output fields, and is very easy to maintain.

    What sort of problem does it cause for you?

    Comment


    • #3
      Re: Loading in array from display file.

      Sounds to me that what you are doing lends itself to using a subfile. You probably don't need an array at all.

      Comment


      • #4
        Re: Loading in array from display file.

        Thanks for replies.

        About 20 years ago it was just me analysing, writing and maintaining a program so there was no problem (although I had some guidelines writing them: using same indicator for CHAIN, READ, error checks, etc. as well as having nearly always a subroutine to load and another one to check a display).

        I would like now to get into RPG IV and need to "translate" RPG II knowledge into RPG IV. That's why I ask some basic things to learn how RPG IV "thinks and acts".
        Of course it's not a problem (just annoying) to do the 5 minute work as Scott Klement says.

        Externally defined files have many advantages from the maintenance point of view (I still wonder why with IDDU/36, IBM did not bind it to RPGII but just to QUERY/36, but it was surely a matter of not wasting sale possibilities of the, in those days, big brother S38).

        @Scott M
        I know a subfile can be a solution and I will find out how to code it in a program.

        Thanks again and all the best.
        Arnaldo

        Comment

        Working...
        X