sponsored links

Collapse

Announcement

Collapse
No announcement yet.

DSPF issue - reading SFL records?

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

  • DSPF issue - reading SFL records?

    OK, I've got a display file issue that is truly boggling my mind.

    In a particular DSPF, I've got several screens. The problem comes between Screen 2 and Screen 3. Screen 2 is a subfile.

    On Screen 2, I have a subroutine that reads thru each record on the subfile, and looks for the option number that the user put in. If the user selects with option '1', the program is supposed to go to Screen 3. This works fine. I select the first record with option '1'.

    I go to Screen 3, and press F12 (*INKL). The RPGLE program recognizes this properly, and processes properly. It returns to Screen 2. The last thing the Screen 3 routines do, before returning to Screen 2, is turn off *INKL. All is well; this works fine. I have confirmed that, when I return to Screen 2, *INKL is off.

    The next thing that happens on Screen 2 is to read the next subfile record. That works great. But when I read the next subfile record, this TURNS *INKL BACK ON, even though F12 was not pressed on Screen 2 at all. I have confirmed (with DEBUG) that this is when *INKL is turned back on. (This, as you might imagine, causes F12 processing on Screen 2, returning the program to Screen 1).

    I've tried having the DDS CA12 keyword at the file level; I've tried moving it down to the record level (and only having it on the subfile control records). Nothing works.

    Any ideas?

  • #2
    Does you display file use INDARA?

    If so, the indicators in the display file are shared by all record formats and the RPG program. The same memory is shared for all of that. So when you re-read the display file, it will return the last known state of the indicators. If you do a WRITE to the display (or EXFMT) with the indicator turned off, that should set it off to prevent this.

    Comment


    • #3
      Thanks for your help!

      No, I don't use INDARA. (I never saw the point, for much the same reasons you describe).

      The relevant code (simplified) looks like this:

      1 DO RRN2Hld RRN2
      RRN2 Chain Scr002S
      If $Select = '1'
      ExSR Screen03
      EndIf
      EndDo

      If $Select = '1' for the first record, this works great. I've verified that it goes into Screen03, and I process Screen03 perfectly. I've verified that it returns properly from Screen03, and that *INKL = *off when it hits the EndIf. And I've verified that the Chain to Scr002S, with RRN2 = 2, is what sets *InKL back on. Again, INDARA doesn't appear in the DSPF.

      Comment


      • #4
        Even though you're not using INDARA, I suspect the fix is the same... you'll need to write a display so that the updated indicator gets written to the display file after it has been turned off. It's worth a try, isn't it?

        I guess its possible that this is a bug that you could report to IBM and ask them to fix it,.

        Comment


        • #5
          How are you doing this part "The next thing that happens on Screen 2 is to read the next subfile record."?
          READC or CHAIN?

          Kit
          www.ecofitonline.com
          DeskfIT - ChangefIT - XrefIT
          Last edited by kitvb1; September 14th, 2016, 12:44 AM.
          Regards

          Kit
          http://www.ecofitonline.com
          DeskfIT - ChangefIT - XrefIT
          ___________________________________
          There are only 3 kinds of people -
          Those that can count and those that can't.

          Comment


          • #6
            Scott -- just to be sure, I added code to write Screen 3 again. That didn't help. Then, I added code to write it again with RMVWDW turned on. Also didn't help.

            Kit -- it's a CHAIN. For a couple of reasons, I want to go thru every subfile record, whether its been changed or not. See the code snippet in the third comment on the thread.

            Comment

            Working...
            X