Re: subfile processing--readc & sflnxtchg

["David Morris" <dmorris@xxxxxxxxxxxxx>]

Valerio & Bob,
I have found that in some cases you must also re-write the control format 
after the updating the records.  I haven't had a need for this in many years, 
so this may not be the case today.  Usually I did this because we always 
process options as sets, for example, all deletes are processed together.  
After a while, I just included the write to the control format between sets of 
readc processing.

This always seemed to work fine, now I use a queue to control the flow of 
logic.  I have found this to be much more flexible.

David Morris

>>> <Spotsyvv@aol.com> 02/11 11:32 AM >>>
Bob,

you can retain the SFLNXTCHG attribute of any SFL record detected by a READC
by simply re-updating the record with the SFLNXTCHG indicator *ON.
This way any subsequent READC will always pick up the changed records.

Valerio V.
County of Spotsylvania, VA

In a message dated 2/11/99 10:43:41 AM Eastern Standard Time,
Bob.Ladutko@bicworld.com writes:

<< I have run into situations where the READC/SFLNXTCHG processing just
doesn't
 meet my needs.  
 
 On occasion, I have to process the same subfile more than once in a single
 pass (prior to the next EXFMT).  READC retrieves the changed subfile
 records, but even with SFLNXTCHG, these records are only retrieved once
 prior to the next EXFMT.
 
 Obvious solutions to this problem:
 
 *      Read the full subfile and compare before/after values (with hidden
 fields) for changes.
 *      Save RRN's after initial READC into an array, and use this array to
 chain back to the subfile for future reads.
 *      Change logic to not read the subfile multiple times.
 *      etc.

+---
| 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
+---