|
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 _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l or email: RPG400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
