ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Strange Indicator Behavior

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

  • Strange Indicator Behavior

    Hello.

    Below is a small program that is has an input primary file and an input secondary file. They point to the same file and that file has two records in it that have different values, so the control break will happen for each record.

    The first time through the program *IN01 is on and the we hit total time, so XHM is executed. When the second (and last) row is read for the primary file *IN01 is on until it gets to the control break where it is shut off and *IN02 in turned on, so XHM2 is executed. Shouldn't *IN01 stay on? I seem to remember a long time ago someone saying that record indicators don't belong in the total section, so maybe that has something to do with it (?).


    ​Thanks in advance,

    Mike

    Code:
    FINPUT1       IP          E                      K DISK
    F                                                                                   RENAME(HAZMATR:INPUT1R)
    FINPUT2       IS          E                      K DISK
    F                                                                                   RENAME(HAZMATR:INPUT2R)
    IINPUT1R                  01
    I                                                                                             HMCO
    I                                                                                             HMID                  L1
    IINPUT2R                  02
    I                                   HMCO                                              XXCO
    I                                   HMID                                                XXID                    L1
    
    C         01                               ADD         1                               LR01                         7 0
    C         02                               ADD         1                               LR02                         7 0
    
    CL1 01                                   EXSR       XHM
    CL1 02                                   EXSR       XHM2
    C************************************************* ***************
    C           XHM                          BEGSR
    C                                             MOVE         HMCO                   HMCO01                  2
    C                                             ENDSR
    C************************************************* ****************
    C           XHM2                       BEGSR
    C                                             MOVE          XXCO                     XXCO02                 2
    C                                            ENDSR
    C************************************************* ****************

  • #2
    Two questions. Why are you defining the file twice? And what are the key fields of the file?

    Comment


    • #3
      The problem originated in another, older, much bigger, production program. This program, above, was written to demonstrate the problem. The key fields shouldn't matter since it's the same file.

      We recently upgraded to 7.5 from 7.3 and the programmer that reported this problem thought IBM had changed the RPG cycle, even though he admitted it was highly unlikely. It's just that this program has been in production forever and there has never been a problem.

      I think using record identifying indicators at total time is a mistake. As I said before I think I remember someone telling me when I was a newbie to not do that.

      Comment


      • #4
        You're right, it's not a good idea. The reason is that in order for the program to determine that a level break has occured, the next record has to be read to see the value of the level break fields (although the field values are not populated from the input buffer until later in the cycle). In this case, the next record is coming from the secondary file since there are no more records in the primary file, so that's why indicator 02 is on when total time calcs are run. It has always worked this way.

        Comment


        • #5
          Record Identifying Indicators are set off at the beginning of each cycle, a record is read, and a Record Identifying Indicator is turned on.

          This is also true for Level Indicators, they are set off at the beginning of each cycle, a record is read, and Level Indicators are set.

          To be meaningful Level Indicators must correspond to the order records are read.

          If HMCO is company and HMID is an identifier within each company, the keys likely are HMCO and HMID and your code should look like:

          Code:
          IINPUT1R                  01
          I                                                                                             HMCO                 L2
          I                                                                                             HMID                   L1​
          Your example code will process all records in the Primary file then all records in the Secondary file. I can't see why you'd read the same file twice. Is the Secondary file redirected by OVRDBF?​

          Comment


          • #6
            Thanks, Brian. That makes perfect sense.

            UserName10, in the production program the file has to be read through once in order to know certain things, like the total number of records to process and totals. I know there's better ways to do it these days (I can't remember the last time I coded an input secondary file) but this is an old program and it's not changing any time soon.

            Thanks for everyone's feedback.

            Comment

            Working...
            X