× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.