Re: SFLNXTCHG head-scratcher -- RPG400-L

Michael,
I have used both methods in the past, but unfortunately, the SFLNXTCHG
function only tells you that the MDT for at least one field on the subfile
record has been changed, not that the actual data was changed.

Jeff Young
Sr. Programmer Analyst

On Fri, May 15, 2015 at 4:21 PM, <MichaelQuigley@xxxxxxxxxx> wrote:

> I do what you're trying to do all the time--it's one of  my standard
> subfile processing methods.
>
> First, I read through all the changed records and validate the
> options/input, set the SFLNXTCHG on, and update the subfile record. Then I
> read through them and process them. But in-between, I reset the RRN
> (RRNSF1 in your case) to zero. If you don't, then you immediately get %EOF
> as there are no more records to process.
>
> It doesn't require IO on the control record, or other finagling. You can
> use hidden fields and do your own comparisons, but why rewrite a basic OS
> function? Go down that path and you can end up writing a bunch of code
> that the OS already handles for you.
>
> "RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx> wrote on 05/13/2015 12:56:25
> PM:
> > ----- Message from Dan <dan27649@xxxxxxxxx> on Wed, 13 May 2015 11:
> > 17:23 -0400 -----
> >
> > 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.
>
>