Sheesh Bill, sooner you then me with this one :-)

All I can tell you is that if there are "changed" records on the subfile
a Z-ADD 1 to the RRN and a READC will read the first changed record.

You are correct in two of your observations:- Hell it just works and the
do loops with chains to
subfile, and mult loops through subfile to check things is is for the
birds.

Have a good one

Paul

"Hopkins, Bill" wrote:
>
> Moved Z-add1 #RRN moved just before READC even though net logic effect it
> the same. Same
> results #RRN3 equal 1 READC on no hit on changed records.
>
> Original code #RRN3 was 998 before and after write of control record.
>
> One other thing I tryed.  The SFLNXTCHG indicator *IN80 was on at
> WRITERC0010C control rec. Was to see if it
> Made a difference I set it to *OFF before write. Still work fine.
>
> I still think Don hit it on the head before about it still thinking it is
> positioned
>  at the last records on subfile after update, even when forcing #RRN3 to 1
> prior to readc.
>
> Also change to load all 1000(subfile size and update all 1000
>  As changed #RRN3 = 1000 at break before readc. Forced #RRN3 to 1 before
> READC.
>
> Same result readc 25 is *on
>
> Think WRITERC0010C is some how cleaning that up subfile position or force of
> SFLNXTCHG updates taking effect.
>
> Hell it just works :).
>
>  I think the person had a design issue when deciding
>  to completely control everything in subfile this way. Instead of
> file/subfile combo
> or at least hidden fields to compare on change.
>  This forcing of change just to readc. And the do loops with chains to
> subfile,
> and mult loops through subfile to check things is is for the birds.
>
> I think 3000 line could have been 1000 or less. And better controlled and
> maintained. Oh Well
>
> Thanks Bill H.
>
> -----Original Message-----
> From: Paul Tuohy [mailto:tuohyp@attglobal.net]
> Sent: Friday, November 08, 2002 8:30 AM
> To: rpg400-l@midrange.com
> Subject: Re: Subfile Next Changed
>
> Hi Bill,
>
> A couple of things to try.
>
> - Try putting the Z-ADD1      #RRN3   in the $VAL3 subroutine on the
> line directly above the first READC.
>
> - Where you are using the Write to the control record debug the program
> and check the value of #RRN3 before and after the Write (a lot depends
> on what SFL indicators are on when you do this Write)
>
> - Looking at the snippet of code, you would have a problem if there were
> not any records in the subfile - has the subfile been loaded? Maybe have
> a look (in debug) at what is happening in the CLEAR loop.
>
> HTH
>
> Paul
>
> "Hopkins, Bill" wrote:
> >
> > I thought my problem was the fact I was at rec 998 of subfile
> > after updating each with the SFLNXTCHG indicator on for each update.
> >  So when I did READC I positioned in subfile below the records
> > I had just updated with change on. This had no hit on readc.
> >
> > So to fix I tryed in debug a z-add 1 to #RRN3 after update.
> >
> > A          R RC00103S                  SFL
> > A  80                                  SFLNXTCHG
> >
> > A     R RC00103C                  SFLCTL(RC00103S)
> > A                                      CF07
> > A                                      CF04
> > A  51                                  CF05
> > A                                      CF11
> > A                                      CF09
> > A                                      CF01
> > A  99                                  ALARM
> > A                                      OVERLAY
> > A                                      SFLCSRRRN(&S@CRS)
> > A  31                                  SFLDSP
> > A  30                                  SFLDSPCTL
> > A  32                                  SFLCLR
> > A  38                                  SFLEND(*MORE)
> > A  36                                  SFLDROP(CF11)
> > A N36                                  SFLFOLD(CF11)
> > A                                      SFLSIZ(1000)
> > A                                      SFLPAG(0006)
> > A            S@CRS          5S 0H
> > A            S@POS          4S 0H      SFLRCDNBR(CURSOR *TOP)
> >
> > FRC0010D CF  E                    WORKSTN
> > F                                        #RRN3 KSFILE RC00103S
> >
> > C                     CLEARX
> > C                     DO   999       X
> > C           X         CHAINRC00103S             25
> > C           *IN25     IFEQ *OFF
> > C                     MOVE *ON       *IN80
> > C                     UPDATRC00103S
> > C                     ENDIF
> > C                     ENDDO
> > C                     Z-ADD1         #RRN3            <<<<<<<<<
> >
> > C                     EXSR $VAL3
> > +++++
> > C           $VAL3     BEGSR
> >  *
> > C                     READCRC00103S                 25
> >  *
> > C           *IN25     DOWEQ*OFF
> >  *
> > +++++
> > Still had problem
> > when breaking on *IN25 DOWEQ *OFF *IN25 was on.
> >
> > So after reading post tryed the following
> > Changed Z-ADD 1 #RRN3 to WRITERC00103 ran again and *IN25 DOWEQ *OFF was
> > *OFF.
> > #RRN3 = 998. READC hit first record changed by update which was record 1
> of
> > subfile.
> >
> > I had same thoughts as you on "How it should work" but wasn't.
> > Anyone see what's up or can explain please do.
> >
> > I think because I did not naturally hit the end of subfile when in update
> > loop.
> > Force of #RRN3 to 1 from 998 before readc really has not happen in the
> > background.
> > And I think the write of the control record reset things in background so
> > change is
> > pick up by readc.
> >
> > Thanks
> > Bill H.
> >
> > -----Original Message-----
> > From: Paul Tuohy [mailto:tuohyp@attglobal.net]
> > Sent: Thursday, November 07, 2002 3:07 PM
> > To: rpg400-l@midrange.com
> > Subject: Re: Subfile Next Changed
> >
> > Hi Bill,
> >
> > Ain't subfiles fun? :-)
> >
> > There has to be something else in here because you definitely do not
> > need to do anything with the subfile control record.
> >
> > This is how READC should work.
> >
> > Every subfile record has a "modified indicator".
> > Typing something into a field on the subfile sets on the "modified
> > indicator".
> > Updating the subfile record with SFLNXTCHG enabled sets on the "modified
> > indicator".
> > A READC will read the NEXT record (i.e. from where the current pointer
> > is, that pointer being the RRN field for the subfile) with a "modified
> > indicator" on.
> > The process of inputing a subfile record sets OFF the "modified
> > indicator".
> >
> > No subfile control record required.
> >
> > So, if subfile records have been updated with SFLNXTCHG enabled then.
> >
> >  C                     Z-ADD1              RRN
> >  C                     READCRC00103S                 25
> >
> > should read the first subfile record that has it's "modified indicator"
> > on.
> >
> > HTH
> >
> > Paul Tuohy
> >
> > "Hopkins, Bill" wrote:
> > >
> > > Way it was explain to me in earlier post. It never reach the end of
> SUBSIZ
> > > of 1000 on update. So readc did not find anything because it started
> from
> > > that point. I ran in STRISDB with z-add SUBFIL RRN to 1 before readc
> still
> > > no hit.
> > > I removed and ran again with write of rc00103c control rec after update
> of
> > > 998 of the subfile records and it worked. Added back in the z-add 1 to
> RRN
> > > so it would be at being in a future loop.
> > >
> > > Thanks Again
> > >
> > > -----Original Message-----
> > > From: Paul Tuohy [mailto:tuohyp@attglobal.net]
> > > Sent: Thursday, November 07, 2002 2:01 PM
> > > To: rpg400-l@midrange.com
> > > Subject: Re: Subfile Next Changed
> > >
> > > Bob,
> > >
> > > You should not need the write of the subfile control record. An update
> > > of a subfile record with SFLNXTCHG on sets the "changed flag". Setting
> > > RRN to 1 and issuing a READC should read the "changed record".
> > >
> > > As to the RRN of 998 - are you sure there are actually 1000 records in
> > > the subfile (as opposed to a size of 1000). At the end of your loop, X
> > > would be 999 but RRN would be 998 if there were only 998 record in the
> > > subfile.
> > >
> > > HTH
> > >
> > > Paul Tuohy
> > >
> > > "Hopkins, Bill" wrote:
> > > >
> > > > Write of control record allowed readc to work
> > > > after subfile next change update of all subfile records.
> > > > z-add 1 to subfile rrn reset it to top.
> > > >
> > > > Will look for why RRN at 998 of 1000 next.
> > > >
> > > > Thanks All
> > > > Bill H.
> > > >
> > > > -----Original Message-----
> > > > From: Paul Tuohy [mailto:tuohyp@attglobal.net]
> > > > Sent: Thursday, November 07, 2002 12:43 PM
> > > > To: rpg400-l@midrange.com
> > > > Subject: Re: Subfile Next Changed
> > > >
> > > > Hi Bill,
> > > >
> > > > Before the READC simply Eval RRN = 1. This is the equivelent of doing
> a
> > > > *LOVAL SETLL on the subfile. You do not need to re-write the subfile
> > > > control record or any such - SFLNXTCHG is a subfile record keyword.
> > > >
> > > > HTH
> > > >
> > > > Paul Tuohy
> > > >
> > > > "Hopkins, Bill" wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > Do not ask why, but this subfile is TRYING to be totally
> > control/edited
> > > by
> > > > > the program before any writes/update to PF.
> > > > > About 3 thousand plus lines.
> > > > >
> > > > > Force change to subfile records?
> > > > >
> > > > >  C                     CLEARX
> > > > >  C                     DO   999       X
> > > > >  C           X         CHAINRC00103S             25
> > > > >  C           *IN25     IFEQ *OFF
> > > > >  C                     MOVE *ON       *IN80             <<<<<<
> > SFLNXTCHG
> > > > >  C                     UPDATRC00103S
> > > > >  C                     ENDIF
> > > > >  C                     ENDDO
> > > > >
> > > > > Skip code(nothing touching subfile) then the following:
> > > > >
> > > > > C                     READCRC00103S                 25
> > > > >  *
> > > > > C           *IN25     DOWEQ*OFF                           <<<<< 25
> is
> > > on.
> > > > On
> > > > > first readc
> > > > >
> > > > > Is this *ON because control rec(RC00103C) to subfile not written or
> > > exfmt
> > > > > before READC? Or RRN to subfile at bottom?
> > > > > Why READC not seeing it as changed?
> > > > >
> > > > > Mind fried trying to find.
> > > > > Thanks
> > > > >
> > > > > Bill H


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.