|
On Fri, 5 Oct 2001, Robin Coles wrote: > > With READ and an indicator, if the record happened to be locked the user > got an error message that was ugly but allowed a retry. It happened so > infrequently and recovery was so painless that we just accepted it. > We've recently switched to using READ(E) and %EoF etc, using code > similar to: > > Read(E) File > Dow Not %EoF > ... Some stuff here > Update File > Read(E) File > EndDo > > but now we don't get the error message if there's a lock, and we fall > through the DoW loop ending up with an update without prior read or > chain. The reason that you're not getting a "lock error message" is because you're specifying "(E)", which means to trap all errors. This is the same (and has the same results) as placing a 2nd indicator in the 'Lo' indicator position. i.e., these two code snippets are functionally the same: C read file 0102 C dow *in02 = *On C read file 0102 c enddo c read(e) file c dow not %eof(file) c read(e) file c enddo This is a bad idea, as you've noted, because in both cases you're telling it that _you_ want to handle any errors (either by specifying (E) or by specifying indicator 01) -- but then you're not handling those errors. Instead, if you're not going to handle them, let the operating system take it's default action. These two snippets of code do that: c read file 02 C dow *in02 = *On c read file 02 c enddo c read file c dow not %eof(file) c read file c enddo Does that make sense? (Or did I miss the point completely?)
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.