Re: SFLNXTCHG head-scratcher

Jeff,

You are correct. The MDT will be set on even for something as trivial as a
field-exit through a blank field. I probably shouldn't have answered this
post toward the end of a hectic day. To know what data changed or whether
any data actually changed, requires access to the old data. This would
probably be best served by hidden fields on the subfile. But the OP's
specific question was about the function of SFLNXTCHG and READC. That's
all I addressed. But as you point out, there's probably more to be
considered than simply reading the record again.

Thanks for keeping me straight on this,
Michael

"RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx> wrote on 05/16/2015 01:00:02
PM:

----- Message from Jeff Young <jyoung0950@xxxxxxxxx> on Fri, 15 May
2015 16:46:07 -0400 -----

To:

"RPG programming on the IBM i (AS/400 and iSeries)"

<rpg400-l@xxxxxxxxxxxx>

Subject:

Re: SFLNXTCHG head-scratcher

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.

--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L) digest 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.