Re: SFLNXTCHG head-scratcher

[Dan <dan27649@xxxxxxxxx>]

> At first glance, shouldn't your READC be against UGLTRA1S, the actual
subfile record?  What's UGLTRA1S?

Crud.  I copied the wrong code.  UGLTRA1S is a different subfile.

> The right order is:
> READC
> SFLNXTCHG = *ON
> UPDATE SFL
> SFLNXTCHG = *OFF

I need to back up a little.  There is an input op on the subfile prior to
updating it (obviously).

In the subfile program, the user can position the cursor on a particular
field in the subfile and use F4 to call a program that uses a window
subfile from which the user can select a valid code and return it to the
original subfile program.  So, that part is covered here:

 * CSRSF1 identifies the subfile record number where the cursor was located
when F4 was hit
C     CSRSF1        CHAIN     MAPTRA1S                           31
 *
C                   CALL      'MAPDRVRG'
C                   PARM                    FLDCSR           10
C                   PARM                    CO#
C                   PARM                    NewLoc
 * NewLoc is the user-selected value from the prompt program
C                   If        NewLoc <> *blanks
 * LOCATN is a field defined in the subfile record
c                   Eval      LOCATN = NewLoc
c                   Eval      SflNxtChg = *on
C                   UPDATE    MAPTRA1S
c                   Eval      SflNxtChg = *off
C                   ENDIF
... No other workstation I/O occurs before:
c                   Exsr      UPDWRK
...
 * This SR is used to update the work file.  The work file is used because
 *  this is a GL batch type file, and the production table can't be updated
 *  until after everything is entered and then posted via F-key.
C     UPDWRK        BEGSR
C                   READC(E)  MAPTRA1S
C                   DOW       %EOF = *OFF
C                             OR (CF04 AND NewLoc <> *blanks)
...   (update the work file)

HERE'S WHAT'S NEW SINCE MY O.P.:  To fix some other issues, I had commented
out the "OR (CF04 AND NewLoc <> *blanks)" line above because I
misunderstood how the READC preceding it would affect the record earlier
chained to when the READC failed w/ EOF.  If the READC results in EOF, the
earlier chained-to record is still in the input buffer.  Ergo, the OR
portion of the condition fits my need. (Just before the ENDDO for this loop
is a test of the same condition to LEAVE the loop. [Not my code.])

SO...  I have resolved the issue by reactivating the OR portion of the
condition, and some other code changes made have the program functioning
again.  But, I am still curious as to why the SFLNXTCHG is not causing the
subsequent READC to pick up the record.

On Wed, May 13, 2015 at 12:14 PM, Bob Cagle <bcagle@xxxxxxxxxxx> wrote:

> Dan
>
> Yes, after updating the subfile record with SFLNXTCHG turned on, a READC
> on the subfile should pick up that record.
>
> At first glance, shouldn't your READC be against MAPTRA1S, the actual
> subfile record?  What's UGLTRA1S?
>
> Could you possibly post more of the code to code.midrange.com and post
> the link to it back here?
>
> Thanks
>
> Bob Cagle
> IT Manager
> Lynk, Inc.
>
> -----Original Message-----
> From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan
> Sent: Wednesday, May 13, 2015 10:17 AM
> To: RPG400-L@xxxxxxxxxxxx
> Subject: SFLNXTCHG head-scratcher
>
> It's been several years... meh, a decade since I last worked with subfiles
> prior to this job I started a few months ago.
>
> Have a situation where SFLNXTCHG is not working as I expect it to.
>
> DSPF:
>      A          R MAPTRA1S                  SFL
>      A  39                                  SFLNXTCHG
>
> RPGLE:
>      FMAPTRADF  CF   E             WORKSTN INFDS(INFDS)
>      F                                     SFILE(MAPTRA1S:RRNSF1)
>      F                                     INDDS(DS@INDDS)
> ...
>      D DS@INDDS        DS
>      d SflNxtChg              39     39n
> ...
>       *** A field defined in the subfile record is updated by the program,
> then...
>      c                   Eval      SflNxtChg =
> *on                              SFLNXTCHG (for READC
>      C                   UPDATE    MAPTRA1S
>      c                   Eval      SflNxtChg =
> *off                             SFLNXTCHG reset
>
> --->  At this point, should a READC pick up the record that was just
> updated?  In the program I'm modifying, the next I/O operation on the
> workstation file is a READC on the subfile.  Does there need to be an
> intervening EXFMT / WRITE of the subfile control record?  I tried a "1
> SETLL  MAPTRA1S" after the update above, but the compiler isn't buying it.
> (Also tried *LOVAL in factor 1.) Here is the code with the EOF test:
>
>      C                   READC(E)  UGLTRA1S
>      C                   DOW       %EOF = *OFF
>
> Given the earlier code, I would have expected the READC to find the
> updated record, but debug is showing that %EOF is *on, and is skipping the
> DOW group.
>
> Ideas, advice appreciated!
>
> - Dan
>
> --
> This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
> mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>
>