MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » February 1999

RE: subfile processing--readc & sflnxtchg


  • Subject: RE: subfile processing--readc & sflnxtchg
  • From: Nagendra <NAGENDRA@xxxxxxxxxxxxxxxxx>
  • Date: Fri, 12 Feb 1999 00:05:47 -0500

fixed

Hi,

Issue a WRITE on Subfile control record to position the pointer again at
the beginning. Then you can again start READC which will now again start
from the beginning.

Bye

> -----Original Message-----
> From: email@james-w-kilgore.com [SMTP:email@james-w-kilgore.com]
> Sent: Friday, February 12, 1999 6:37 AM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: subfile processing--readc & sflnxtchg
> 
> Bob,
> 
> Here's where we "force" SFLNXTCHG to occur:
> We have a panel that displays a subfile and permits a user to make
> changes.
> When the EXFMT kicks the program back in gear, we start a
> READC/validate/process
> loop.
> If any errors are detected during the validate portion, we turn on our
> handy
> dandy universal error indicator (along with reverse image, etc.) and
> UPDAT the
> subfile record with the SFLNXTCHG conditioned by the universal error
> indicator.
> 
> Now in your case, if I hear you right, you want to do two or more
> READC loops,
> maybe one to validate and another to actually process.  If that is the
> case, you
> would need to UPDAT each changed subfile record to get READC to work
> on the
> second loop.
> 
> Maybe in you case, condition SFLNXTCHG by an "OK" indicator.
> 
> HTH,
> 
> James W. Kilgore
> email@James-W-Kilgore.com
> 
> 
> "Ladutko, Bob" wrote:
> 
> > Maybe I'm confused on my thinking (it's happened before).  I'll have
> to look
> > through some programs tonight.
> >
> > I was thinking that when a READC is performed, and a changed record
> is
> > retrieved, it wouldn't be retrieved again until the next EXFMT if
> you use
> > SFLNXTCHG.  My question is how exactly would that same record be
> retrieved
> > during the same pass?  Would I have to CHAIN to a prior record 1st
> so that
> > the READC will work again or what?  (I'm comparing this to a READ to
> a
> > physical file - if I want to READ a record again, I have to
> reposition the
> > file.)  If this is how to do it, what if the 1st record in the
> subfile was
> > changed?  Since I can't do a SETLL, how can I retrieve that record
> again
> > with READC?
> >
> > Is my thinking as flawed as it seems to be?
> >
> > Bob L.
> >
> > > -----Original Message-----
> > > From: Fisher, Don [SMTP:DRF@HeiligMeyers.com]
> > > Sent: Thursday, February 11, 1999 12:41 PM
> > > To:   'MIDRANGE-L@midrange.com'
> > > Subject:      RE: subfile processing--readc & sflnxtchg
> > >
> > > Yes, I know, but he said "...but even with SFLNXTCHG, these
> records are
> > > only
> > > retrieved once prior to the next EXFMT."  This implies he has
> examples
> > > where
> > > setting on SFLNXTCHG does not force READC to pick up the records
> during a
> > > second pass unless another EXFMT is executed.  Did I
> misunderstand, Bob?
> > >
> > > Donald R. Fisher, III
> > > Senior Programmer/Analyst
> > > Heilig-Meyers Furniture Company
> > > (804) 784-7500 ext. 2124
> > > Don.Fisher@HeiligMeyers.com
> > >
> > >
> > > -----Original Message-----
> > > From: Stone, Brad V (PP) [mailto:bvstone@ppress-tc.com]
> > > Sent: Thursday, February 11, 1999 11:42 AM
> > > To: 'MIDRANGE-L@midrange.com'
> > > Subject: RE: subfile processing--readc & sflnxtchg
> > >
> > >
> > > He is referring to trying to do two passes on the subfile before
> writing
> > > again.  Once you've read the changed records, they are no longer
> changed.
> > > You could use an indicator on the SFLNXTCHG keyword and be sure to
> set it
> > > on
> > > and update the subfile after each READC.  I'm sure there are other
> methods
> > > as well.
> > >
> > > Bradley V. Stone
> > > Taylor Corporation - OASIS Programmer/Analyst
> > > bvstone@taylorcorp.com
> > >
> > > +---
> > > | This is the Midrange System Mailing List!
> > > | To submit a new message, send your mail to
> MIDRANGE-L@midrange.com.
> > > | To subscribe to this list send email to
> MIDRANGE-L-SUB@midrange.com.
> > > | To unsubscribe from this list send email to
> > > MIDRANGE-L-UNSUB@midrange.com.
> > > | Questions should be directed to the list owner/operator:
> > > david@midrange.com
> > > +---
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to
> MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to
> MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> david@midrange.com
> > +---
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact